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-adapti... 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@jesup.org