Confused, Timid, and Unstable: Picking a Video Streaming Rate is Hard

Transcription

1 Confused, Timid, and Unstable: Picking a Video Streaming Rate is Hard Araz Jangiaghdam Seminar Networks and Distributed Systems School of Engineering and Sciences Jacobs University Bremen Campus Ring 1, Bremen, Germany Monday 15 th April, 2013

2 Presentation Outline Introduction Issue Outline Proposed Solution Conclusions

3 Introduction Issue Outline Proposed Solution Proposed Solution Conclusions Video streaming huge fraction of internet traffic video is streaming services Netflix and Youtube account for over 50% of the peak dl traffic in the US three popular HTTP-based video streaming services (Hulu, Netflix, Vudu) Each AS administers a set of routing prefixes e.g /12 video streamed over HTTP, video service provider relies on TCP to find the available bandwidth and choose a video rate accordingly

4 Video streaming big video streaming services run over HTTP and TCP and stream data to the client from one or more third-party commercial CDNs (e.g. Akamai, Level3 or Lime- light)

5 Video streaming video services do poorly when there is a competing traffic (another video stream, a backup, or a large download) (video is streamed at only 1/7th of its fair share of the available bw)

6 Video streaming:measurments download strategies

7 Video streaming: measurments NetFPGA bandwidth limiter and proxy. The video streaming service provider must pick the highest safe video rate: If too high, the viewer will experience annoying rebuffering events; if too low, the viewer will experience poor video quality.

8 downward spiral: throughput drops (Service A and B) downward spiral effect ( Network bottleneck set to 5Mbs. RTT from client to server is 20ms) - Service A: a web-browser client sends HTTP requests to the CDN, requesting four second chunks of video over a persistent TCP connection. - the client reads the whole video from the same server. - requests the lowest video rate, continuously estimates the available bandwidth, and only picks a higher rate if it believes it can sustain it. - Why does throughput of the video flow drop so much below available fair-share bandwidth? Is it a characteristic of streaming video over HTTP, or is the client simply picking the wrong video rate?

9 downward spiral (Service C HD) downward spiral effect ( Network bottleneck set to 22Mbs and 5 22Mbs) While Service A controls the occupancy of the playback buffer by varying the rate at which they request new segments, Service B and Service C rely on the TCP receive window: when the playback buffer is full, TCP reduces the receive window to slow down the server.

10 downward spiral (Service A) disable automatic rate selection, maintain the highest playback rate (with no rebuffing event) the downward spiral effect is caused by underestimation of the available bandwidth in the clients rate selection algorithm. The bandwidth is available, but the client needs to go grab it.

11 downward spiral TCP throughput, Request interval Before and after the playback buffer fills (cwnd times out, the client is using an existing persistent TCP connection, the cwnd needs to ramp up from slow start for each new segment download. )

12 downward spiral The client picks a video rate depending on the available bandwidth. (bottleneck link rate drops every 3 minutes by 100kbps to mimic the competing flow)

13 Proposed Solution The evolution of cwnd for different segment sizes (5 times larger chunk size) (The competing flow fills the buffer during the OFF period, so the video flow sees high packet loss. The chunk is finished before cwnd climbs up again, and we re-enter the OFF period. The process will repeat for every ON-OFF period, and the throughput is held artificially low.)

14 downward spiral rate selection based on inaccurate estimates(client-side bandwidth estimation above the HTTP layer) triggers a feedback loop, leading to undesirably variable and low-quality video the downward spiral effect phenomenon

15 downward spiral effect: chunk size The segment size for different video rates (...)

16 downward spiral effect: summary of the problem when the playout buffer is full, the client enters a periodic ON-OFF sequence. The OFF period makes the TCP connection idle for too long and reset its congestion window. Also during the OFF period, the competing tcp flow fills the router buffer, so the video flow sees high packet loss once it is back to the ON period. Worse still, the video could finish downloading its video chunk before its cwnd climbs up to its fair share and thus re-enters the OFF period. This process repeats for every ON-OFF period; as the consequence, the video flow underestimates the available bandwidth and switches to a lower video rate. When switching to a lower rate, the client requests for a smaller video chunk, which makes the video flow further underestimate the available bandwidth, forming a vicious cycle.

17 Proposed Solution Main idea consider three changes: being less conservative: Conservatism of 40% means theclient requests for a video rate at highest of 1.2Mb/s when perceived 2.0Mb/s changing the filtering method aggregating chunks

18 Proposed Solution bigger chunks give us better estimates of the available bandwidth, allowing TCP to escape slow-start (Figure shows what happens if client aggregates five requests into one. With the larger chunk size, the perceived throughput is more stable, and both the playback rate and buffer size are more stable.)

19 Conclusions larger chunks let TCP get its fair share and improve the perceived throughput. Picking higher rates less conservatively can improve video quality. But we should note that these improvements are for one movie on one service. Given the prevalence of the downward spiral effect, these should not be interpreted as hard recommendations; merely as added detail to our understanding of the problem.

20 Questions?