Paper: What Happens when HTTP Adaptive Streaming Players Compete for Bandwidth?

Dan Rayburn | Tuesday May 1, 2012 | 04:23 PM | Comments (4)

Screen shot 2012-05-01 at 4.06.24 PMThe College of Computing at Georgia Institute of Technology and the Video & Content Platforms Research and Advance Development Division at Cisco have published a white paper on HTTP adaptive streaming. The paper focuses on the problem of competing video players and describes how the typical behavior of an adaptive streaming player in its Steady-State, which includes periods of activity followed by periods of
inactivity (ON-OFF periods), is the main root cause behind three performance problems: player instability, unfairness between players, and bandwidth underutilization.

I haven’t had the chance to read the paper yet and won’t be able to until after my streaming media shows are over, but others are welcome to comment on the paper in the comments section below. The authors have said they welcome any feedback or questions.

Filed in Content Delivery | Permalink | Comments (4)

Related Posts

  • Andrew null Wise

    Interesting paper and not too long – well done

  • http://www.id3as.co.uk Dom Robinson

    Had a look at the paper and as a standalone document its well written and quite interesting. That said i think it sidelines some key factors and I’m not 100% convinced about their model and the evidence it produces.
    Critically they say “An important point is that the issues we focus on in this paper, are not due to TCP dynamics, as is often reported, but they mainly arise from the rate adaptation algorithms at the application layer”. The underlying TCP Congestion protocols running between the sites’ router and the router connecting the CDN’s server to the internet will be ensuring that this ‘On On’ scenario they then go on to describe is generally avoided. Certainly this should be the case between two DIFFERENT machines behind the same router. The test they describe indicates that they ran multiple players (silverlight) at the same time. That would indicate a browser launched page which would indicate that the router would see all these requests as coming from the same application at the same time and would assume application layer control. This scenario would be very different if the silverlight players were running on separate machines, since at that point the TCP Congestion algorithms would kick in and fill the window available to each application separately ensuring that the On THEN on sequence is filling the pipe, but the ‘on on’ scenario doesn’t happen. In effect both applications would neatly share the bandwidth, but it will very quickly settle down providing the streams and filling of the windows were relatively consistent. I’m frankly not surprised that the browser isn’t managing the flow between the silverlight instances well – i am not aware of anything ‘standard’ that could manage that – HTTP TCP is always best effort with little flow control. What is slightly concerning is that this practical evidence seems to be interpreted as something going on ‘in the network’ – and i don’t think this is the case. Happy to be proven wrong, but it seems that the dismissal of TCP dynamics to then go on to comment on TCP dynamics is questionable.

  • http://www.id3as.co.uk Dom Robinson

    Just to add – if they ran this on a switch connected to a server directly – no router involved – it would give a clean picture – however the available bandwidth on a switched LAN would probably mean they wont have any visible contention issues unless they simulate a large load and high bandwidth streaming – not in itself a congested scenario….

  • mike

    Check out Apple Tv vs Roku for the latest on these amazing streaming players!