
nanog mailing list archives
[SPAM] Re: Forward Erasure Correction (FEC) and network performance
From: Jean-Michel Planche <jmp () witbe net>
Date: Sat, 11 Apr 2009 01:57:38 +0900
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 periodsIt 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)of good network performance ?
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 () witbe net www.witbe.net 1.0 www.internetforeveryone.fr 0.0
Current thread:
- Forward Erasure Correction (FEC) and network performance Marshall Eubanks (Apr 10)
- Re: Forward Erasure Correction (FEC) and network performance Patrick W. Gilmore (Apr 10)
- Re: Forward Erasure Correction (FEC) and network performance Mikael Abrahamsson (Apr 10)
- [SPAM] Re: Forward Erasure Correction (FEC) and network performance Jean-Michel Planche (Apr 10)
- Re: Forward Erasure Correction (FEC) and network performance Matthew Kaufman (Apr 10)
- Re: Forward Erasure Correction (FEC) and network performance Lamar Owen (Apr 10)
- Re: Forward Erasure Correction (FEC) and network performance Matthew Kaufman (Apr 10)
- Re: Forward Erasure Correction (FEC) and network performance Mikael Abrahamsson (Apr 10)
- Re: Forward Erasure Correction (FEC) and network performance Lamar Owen (Apr 10)