Confused, Timid, and Unstable: Picking a Video Streaming Rate is Hard Five students from Stanford • Published in 2012 • ACM’s Internet Measurement Conference (IMC) • 23 citations • Ahmad Tahir 1/26
o Problem o Background Knowledge o Research Motivation o Experimental Setup o First Results The streaming video quality deteriorates when another competing flow for a o Downward Spiral limited bandwidth starts. o Intervention Maintaining a careful balance between: o Before, After not wanting to cause a re-buffer not wanting to deliver unnecessarily low quality 2/26
o Problem Typical HTTP streaming setup o Background Knowledge Client must pick what to request • o Research Motivation o Experimental Setup Careful balance for user satisfaction • o First Results o Downward Spiral o Intervention o Before, After 3/26
Problem How well do they pick what to request? Background Knowledge o Research Motivation o Experimental Setup o First Results o Downward Spiral o Intervention o Before, After 4/26
It’s bad Maximum:5 Mb/s Fair Share: 2.5 Mb/s Optimal: 1.75 Mb/s Used: 235 kb/s What makes this so difficult? 5/26
Problem Services are similar - not identical Background Knowledge Research Motivation Ways to stream HTTP video: o Experimental Setup Web browser vs. PS3 • o First Results o Downward Spiral Single connection vs. many • o Intervention Entire file vs. chunks • o Before, After 6/26
Implementation Details 7/26
Network Parameter Controls NetFPGA rate limiter: 5 MB/s Competing flow: same file, same CDN, simple TCP file download 8/26
Problem No surprises - they’re terrible • Background Knowledge Repeated 76 times over four days • Research Motivation Experimental Setup 91% of cases failed predictably • o First Results o Downward Spiral o Intervention o Before, After 9/26
10/26
Sanity Check? 11/26
Problem Follow the spiral down Background Knowledge Research Motivation Monitor everything: Experimental Setup TCP throughput First Results • o Downward Spiral Buffer size • o Intervention Request interval • o Before, After Congestion window • Where do these algorithms go wrong? 12/26
Client Network Behavior 13/26
TCP Congestion Window • Times out in 4s OFF period • Reset to initial value of 10 packets, every time • Single persistent connection • Ramp up from slow start for each segment anyway • No competing flow? No problem 14/26
Completely Squashed 15/26
Rational Behavior 16/26
A More Complete Picture • Playback buffer fills – starts periodic ON-OFF • During OFF period: • Video stream congestion window idle resets • Competing flow is still going, filling the routers buffer • ON period starts: • Very high initial packet loss • Estimate artificially low bandwidth • Lower playback rate 17/26
The “Spiral” Part • ON period starts: • Very high initial packet loss • Estimate artificially low bandwidth • Lower playback rate – which means shorter segments • Each estimate is ever lower than the previous • Spiral down until you can’t play lower quality 18/26
Another Thing - Timing 19/26
Problem Mimic Service A Background Knowledge Research Motivation Experimental Setup First Results Downward Spiral o Intervention o Before, After 20/26
Less Conservative • Service A ~40% • Try out 10% 21/26
Better Filtering • Service A: ten sample moving average • Try: 80 th percentile 22/26
Finally: Bigger Segments 23/26
Problem Background Knowledge Research Motivation Experimental Setup First Results Downward Spiral Intervention o Before, After 24/26
To Conclude • On the one hand, there are changes to how the client estimates bandwidth which can improve its interplay with TCPs congestion control • A more radical solution: • Don’t attempt to estimate bandwidth at all • Competing goals: highest bitrate, and no underruns • Goal is NOT “keep the buffer full” • Goal is “don’t let the buffer get empty” • Increase the playback bitrate when the buffer is high • Decrease the playback bitrate when the buffer is low • Perfect layer of separation: • TCP responsible for delivering fair share bandwidth • Video player responsible for showing the highest rate it can 25/26
Questions Thank you for listening 26/26
Recommend
More recommend