Forward Erasure Correction (FEC) and network performance
Mikael Abrahamsson
swmike at swm.pp.se
Fri Apr 10 15:36:07 UTC 2009
On Fri, 10 Apr 2009, Marshall Eubanks wrote:
> 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 ?
My personal opinion is that 10^-12 BER per-link requirement in ethernet
sets an upper bound to what can be required of ISPs. Given that a full
sized ethernet packet is ~10kbits, that gives us 10^-7 packet loss upper
bound. Let's say your average packet traverses 10 links, that gives you
10^-6 (one in a million) packet loss when the network is behaving as per
standard requirements (I'm aware that most networks behave much better
than this when they're behaving optimally).
Personally, I'd start investigating bit error rates somewhere around 10^-5
and worse. This is definitely a network problem, whatever is causing it. A
well designed non-congesting core network should easily much be better
than 10^-5 packet loss.
Now, considering your video case. I think most problems in the core are
not caused by actual link BER, but other events, such as re-routes,
congested links etc, where you don't have single packet drops here and
there in the video stream, instead you'll see very bursty loss.
Now, I've been in a lot of SLA discussions with customers who asked why
10^-3 packet loss SLA wasn't good enough, they wanted to raise it to 10^-4
or 10^-5. The question to ask then is "when is the network so bad so you
want us to tear it to pieces (bringing the packet loss to 100% if needed)
to fix the problem". That quickly brings the figures back to 10^-3 or
even worse, because most applications will still be bearable at those
levels. If you're going to design video codec to handle packet loss, I'd
say it should behave without serious visual impairment (ie the huge blocky
artefacts travelling across the screen for 300ms) even if there are two
packets in a row being lost, and if the jitter is hundreds of ms). It
should also be able to handle re-ordering (this is not common, but it
happens, especially in a re-route case with microloops).
Look at skype, they're able to adapt to all kinds of network impairments
and still deliver service, they degrade nicely. They don't have the
classic telco "we need 0 packet loss and less than 40ms jitter, because
that's how we designed it because we're used to SDH/SONET".
--
Mikael Abrahamsson email: swmike at swm.pp.se
More information about the NANOG
mailing list