[R-C] Packet loss response - but how?

[Randell Jesup]

On 5/4/2012 1:40 PM, Jim Gettys wrote:
> On 05/04/2012 01:31 PM, Bill Ver Steeg (versteb) wrote:
>> Randell-
>>
>> Yup, this all makes sense.
>>
>> Regarding Netflix and other ABR flows......
>>
>> I would add that the increasing prevalence of bursty Adaptive BitRate
>> video (HTTP get-get-get of 2-10 second chunks of video) makes the
>> detection of spare link capacity and/or cross traffic much more
>> difficult. The ABR traffic pattern boils down to a square wave pattern
>> of a totally saturated last mile for a few seconds followed by an idle
>> link for a few seconds. The square wave actually has the TCP sawtooth
>> modulated on top of it, so there are secondary effects. Throw in a few
>> instances of ABR video on a given last mile and things get very
>> interesting.
>>
>> The solution to this problem is not in scope for the RTCWeb/RTP work,
>> but I sure wish that the ABR folks would find a way to smooth out their
>> flows. We have been knocking around some ideas in this area in other
>> discussions, so if anybody is interested in this please drop me a note.
> I posted an example of what happens on google+ a while back.
>
> https://plus.google.com/u/0/110299325941327120246/posts
>
> It's pretty grim.

Yes it is.  I've been discussing similar issues with Mozilla developers 
working on DASH.

An interesting overview of Adobe (and likely NetFlix is similar), 
Microsoft, Apple, and a representative DASH implementation:
http://www.slideshare.net/christian.timmerer/an-evaluation-of-dynamic-adaptive-streaming-over-http-in-vehicular-environments

Note that the Apple case seems different than yours - probably desktop 
and not IPad; but it also shows deep buffers and energy awareness.

Some other adaptation/congestion-control work for DASH is at 
http://www.cs.tut.fi/~moncef/publications/rate-adaptation-IC-2011.pdf. 
I've only skimmed it...

> Worse yet, since TCP's responsiveness is quadratic to the delay, these
> bursty elephant flows aren't going to want to get out of the way when
> there is no AQM present.  And our current broadband edge typically has
> no classification: your real time packets gets stuck behind these
> sprinting flows.
>
> Someone with more packet tweezing skills than I have might be able to
> use TCP timestamps that may be in the flows to figure out how much this
> is impulsing the delay.

I'm sure it's possible.  Or run a voip call with G.711/etc at the same 
time to your cellphone, and count the 'clap' or number-count delay, or 
read the delay out of wireshark (especially easy with RTCP packets).

-- 
Randell Jesup
randell-ietf at jesup.org