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

[Jim Gettys]

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.

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.
                          - Jim




<https://plus.google.com/u/0/110299325941327120246/posts>