[SPAM] Re: Forward Erasure Correction (FEC) and network performance

Jean-Michel Planche jmp at witbe.net
Fri Apr 10 16:57:38 UTC 2009


Le 11 avr. 09 à 00:03, Marshall Eubanks a écrit :

> What level of packet loss would trigger response from network  
> operators ? How bad does a sustained packet loss need
> to be before it is viewed as a problem to be fixed ? Conversely,  
> what is a typical packet loss fraction during periods
> of good network performance ?
It really depend on a lot of parameters and it's why I think this  
approach is not relevent at all since IP centric solutions.
In past, some peoples said that if you loose less than 0,1% of packet,  
all is good.
Now, you can loose 1% of packet and acheive something that work for  
the end user with Flash 10 technology and ... despite all you can  
loose 0,01% packet and see a lot of defaults because HD / 8 Mbps /  
H264 encoding. (we've presented that with Cisco last year at IBC  
Amsterdam)

Fortunatly if you thing about IP centric solution, you can install  
enough intelligence in the Set Top Box, for exemple or on a PC client  
side in order to :
	- re-ask paquets
	- and / or repair missing one (fec)
Booth of this solution are in operation today and permit a really not  
too bad IPTV with DSL long lines in many operators that I know.


> (To be clear, I am aware that many ISPs offer some sort of MPLS  
> service with a packet loss SLA for video carriage. I am really  
> asking about
> Internet transport here, although I would be pleased to learn of  
> MPLS statistics if anyone wants to provide them.)
You can ask what you want to yours ISP but the magic is : all can  
happen and loss packet and jitter are not relevent at all !
Then solution is not to ask 100% SLA to ISP (except if you find some  
crazy man to offer you this with good penalty) but to take care about  
your service, with a real end to end monitoring. There is no more  
correlation between backbone artefacts and human artefacts. Best way  
is a user centric monitoring, top down approach that can understand if  
all is good at service / application / usage level, in order to  
control principal real artefacts (blockiness, jerkiness, bluriness and  
availability of image and sound). That's exist, you can believe me ;-)






----------------------------------------------------------------------------------------------------------------------------------
Jean-Michel Planche			www.jmp.net				www.twitter.com/jmplanche 		2.0
jmp at witbe.net				www.witbe.net 											1.0
www.internetforeveryone.fr 															0.0







More information about the NANOG mailing list