Re: [codec] So many emails...

["Christian Hoene" <[e-mail]>]

Hi Mikael,

>Back after IETF75 I posted some network characteristics and examples of
>these, and how I thought the "solution" (not only the codec) should
>behave. There also was some discussion regarding where this should be
>handled and what part was codec and what was transport.
>
>Is there some agreement regarding these issues, and in that case, where
>could I read about that?

#17: Feedback and control loop?
http://www.ietf.org/mail-archive/web/codec/current/msg01522.html
Koen wrote something about the impact of handovers many months ago. However, I do not find his email anymore.
I made some comments at http://www.ietf.org/mail-archive/web/codec/current/msg00660.html

>
><http://www.ietf.org/mail-archive/web/codec/current/msg00865.html> is the
>email I'm talking about.

Let me cite the email again:

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of Michael Knappe
>Sent: Tuesday, November 10, 2009 10:02 AM
>To: Mikael Abrahamsson; [e-mail]
>Subject: Re: [codec] questions to be answered
>
>Mikael,
>
>Thanks for the very useful industry examples and metrics. Handling of these examples fall either into
>jitter buffer design (which so far in the BoF email correspondence, other than noting the need for
>some form of adaptive jitter buffer algorithm, is being treated as largely outside the scope of the
>proposed WG) 

Jitter buffering is not explicitly mentioned in the Codec BOF. However, it must be considered because the requirements regarding
testing. As stated in http://www.ietf.org/mail-archive/web/codec/current/msg01527.html, we shall test the codec using real trace of
IP packets. 
These tests can only be made with some kind of dejitter buffer between packets and codec. Thus, at some point of time, we must agree
which playout buffer to take for the testing.

Christian


>or packet loss concealment (which IS often tied to the codec's design). As you've noted,
>other than doing the best it can to maintain a balance between the impairment due to end-to-end
>latency and impairment due to periods of packet loss concealment, there is really no crystal ball that
>can be employed to recover large numbers of consecutively lost packets during wildly varying jitter
>conditions.
>
>As you mention in your email, it is possible to more tightly couple PLC and the jitter buffer. For
>instance, a proposed codec's decode operation could provide an intelligent feedback loop to the jitter
>buffer at the receiving end to let it know how well it's packet loss concealment algorithm is
>currently operating - for instance telling the jitter buffer to go ahead and rapidly increase its size
>if the PLC algorithm is simply falling apart under enormous packet loss. There are also examples of
>time varying / frequency invariant 'stretch' jitter buffers that are an integral component of the
>codec design, and we should treat them as a whole while evaluating any such proposed codecs.
>
>Mike
>
>
>On 11/10/09 12:03 AM, "Mikael Abrahamsson" <[e-mail]> wrote:
>
>On Mon, 9 Nov 2009, Henry Sinnreich wrote:
>
>> Metrics and values/numbers would be very interesting if you can share
>> them, to better understand the requirements. Also to make sure in what
>> usage scenarios they may occur.
>
>2 seconds jitter and 10% continous random packet loss should definitely be
>handled gracefully (during the tsunami where several fiber optic cables
>were severed in asia, packet loss from the region to the rest of the world
>was continous 5-7% due to remaining paths being extremely congested). 2
>seconds is for multiple links in a row being full (typically Cisco 12000
>routers can buffer 600ms of data when congestion occurs). There are
>numerous cases (ADSL2+ without interleave, high speed links with CRC
>errors, ethernet duplex errors) where random packet loss can be seen.
>Typically this is less than 1%, otherwise people tend to fix the problem
>because TCP works very badly.
>
>We then have the 3G/wifi network issue, where jitter can also be at least
>2 seconds, plus packet loss as well (some networks seem to buffer X
>kilobytes, some Y number of packets, after that they tail drop. I've seen
>both behaviours).
>
>Burst loss, where when you have a network re-route, you might lose
>typically 0.05 - 2 seconds of data, and you might get re-ordering during
>the convergence. Since this is a transient event, I don't think much can
>be done about it but try to play data as they come in and just ignore out
>of order packets. Perhaps jitter buffer should be increased when
>out-of-order packets is seen, but when things calm down again it needs to
>be reduced again.
>
>I've also seen networks which re-order packets constantly, I don't know
>what the load-sharing algorithm used is, but I think the jitter buffer
>size should be adapted and handle out of order packets so they're
>presented to the codec correctly.
>
>When running voice over GSM GPRS, typically there is very low bandwidth
>and high delay. Here bw should be kept as low as possible and the IP
>header is a big overhead and pps should thus be kept at a minimum, for
>instance 3-5 pps and the very lowest quality setting should be used.
>
>So, the SYSTEM (I'm not just talking codec here), as far as I can see it,
>needs to gracefully handle at least 10% packet loss, out of order packets
>(analyse the time they might be re-ordered and adapt jitter buffer
>accordingly), or just plain jitter up to 2s.
>
>My reasoning here is mainly focused on voice over Internet, but as far as
>I can see this applies to all sound, even though if it's not interactive I
>guess the focus can be switched from low latency (it might be better for a
>voice call to have lower latency than actually getting perfect sound) to
>reliable sound delivery with higher latency (by increasing jitter buffer
>and putting sound information in multiple packets so that single packet
>loss doesn't mean silence in that interval). Basically I'd like to see
>that as soon as jitter buffer is increased, the resiliancy to packet loss
>should be increased as well by telling the other end that it can start to
>do packet loss concealment information in the packets as well (whatever
>it's called, I'm not a codec guy). If sender knows what the receiver
>jitter buffer is, then this can be used to increase resiliency (I guess).
>
>Does this help?
>
>--
>Mikael Abrahamsson    email: [e-mail]
>_______________________________________________
>codec mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/codec
>
>_______________________________________________
>codec mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/codec




>
>--
>Mikael Abrahamsson    email: [e-mail]
>_______________________________________________
>codec mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/codec