1 / 41

IEEE JSAC Special Issue Adaptive Media Streaming

IEEE JSAC Special Issue Adaptive Media Streaming. Submissions by April 1 Details at http://www.jsac.ucsd.edu/Calls/adaptivemediastreamingCFP.pdf. Packet Video Workshop 2013 San Jose, CA (@ Cisco). December 12/13, 2013 (Right after PCS 2013) Submissions by m id June

hop
Download Presentation

IEEE JSAC Special Issue Adaptive Media Streaming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IEEE JSAC Special IssueAdaptive Media Streaming Submissions by April 1 Details at http://www.jsac.ucsd.edu/Calls/adaptivemediastreamingCFP.pdf

  2. Packet Video Workshop 2013San Jose, CA (@ Cisco) December 12/13, 2013 (Right after PCS 2013) Submissions by mid June http://pv2013.itec.aau.at/

  3. Server-Based Traffic Shaping for Stabilizing OscillatingAdaptive Streaming Players Saamer Akhshabi, Lakshmi Anantakrishnan, Constantine Dovrolis Ali C. Begen

  4. Briefly … • Problem • When multiple adaptive streaming players compete for bandwidth, we have several problems: • Instability • Unfairness • Bandwidth underutilization • Objective • A server-based traffic shaping solution to mitigate the oscillation problem without significant loss in utilization

  5. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Results • Conclusions

  6. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Results • Conclusions

  7. Adaptive Streamingover HTTP • Media is split into “chunks” • Each chunk corresponds to a certain amount of content • Each chunk is encoded atmultiple bitrates • Clients request chunks based on their estimate of available bandwidth From IIS Smooth Streaming Website

  8. Typical Behavior of a Player • One chunk per HTTP request • Two states: • Buffering • Request chunks as fast as possible • Build up the playback buffer • Steady • Request a new chunk every T seconds • Keep buffer size constant • ON-OFF download pattern • Estimate avail-bwwith running average of per-chunk TCP throughput measurements

  9. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Instability • Bandwidth underutilization • Unfairness • Stabilization method and demonstration • Results • Conclusions

  10. Simple Model: Two Competing Players • Shared link • Capacity C • Fair share = C/2 • Based on the temporal overlap of the ON-OFF periods of the players three performance problems can arise • Instability • Unfairness • Bandwidth underutilization • Two competing adaptive streaming players • Steady-State • Full buffers • Ideal TCP • A single active connection gets entire capacity C • Two active connections share the capacity fairly receiving C/2 each

  11. The Root Cause of Oscillations ON ON ON ON • Both players measure per-chunk throughput of more than C/2 • Overestimate the fair share (f=C/2) • They will request bitrate greater than f, if available • Oscillations • Bandwidth underutilization • Unfairness One player ON Chunk download ON ON ON Both players OFF Both players ON Tseconds

  12. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Server-based shaping solution • Experimental setup • Stabilization method • Results • Conclusions

  13. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Server-based shaping solution • Experimental setup • Stabilization method • Results • Conclusions

  14. Traffic Shaping Solution: Basic Idea • A server-side stabilizer module • Client independent • Basically, a reactiveand adaptive traffic shaper • The stabilizer • Remains inactive if there is no client-side instability • When instability is detected, stabilizer shapes requested video chunks at the rate of a lower profile • Client will then measure lower throughput, and it will return (and hopefully stabilize) to a lower profile

  15. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Server-based shaping solution • Experimental setup • Stabilization method • Results • Conclusions

  16. Experimental Methodology • DummyNet • Stabilizer • DummyNet • Sets the capacity of the share bottleneck • Wireshark • Captures the traffic for offline analysis • Server • Hosts the video content in multiple bitrates • Host for stabilizer • Clients • Simpler player • Logs internal parameters • Does not render video • Smooth Streaming player

  17. Implementation • Server: Smooth Apache module: • http://smoothstreaming.code-shop.com/trac/wiki/Mod-Smooth-Streaming-Apache • Shaping done with Apache mod_bw module: • http://bwmod.sourceforge.net • Shaping module is modified to implement the stabilizer

  18. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Server-based shaping solution • Experimental setup • Stabilization method • Results • Conclusions

  19. Relation between Shaping Rate and Chunk Encoding Rate Ideal Case Shaping Player-1 • Eliminate OFF periods by shaping each chunk so that its download takes about T seconds • Shape the chunk to the average encoding rate for that chunk • In practice, the shaping rate is set to a slightly higher value than the encoding rate (r/c) • Shaping slack parameter c (0.7 in this study) ON ON ON ON ON Player-2 ON ON Tseconds Tseconds ON ON ON ON Both players OFF Both players ON Chunk download One player ON

  20. Relation between Shaping Rate and Chunk Encoding Rate Real Scenario Shaping Player-1 • Eliminate OFF periods by shaping each chunk so that its download takes about T seconds • Shape the chunk to the average encoding rate for that chunk • In practice, the shaping rate is set to a slightly higher value than the encoding rate (r/c) • Shaping slack parameter c (0.7 in this study) ON ON ON ON ON Player-2 ON ON Tseconds Tseconds ON ON ON ON Both players OFF Both players ON Chunk download One player ON

  21. Outline

  22. Oscillation Detection • Detecting direction changes • Direction change defined as a change in the requested profile (upshift or downshift) that is different than the last such change • When two or more direction changes occur within W successive chunks, an oscillation is detected and the player is flagged as unstable • Parameter W is the detection window size

  23. Oscillation Detection

  24. Initial Shaping Rate Selection • Goal is to find the highest sustainable profile • Consider a set of candidate profiles • Highest profile is obviously not sustainable • Shaper starts by setting the initial shaping rate to the next highest profile

  25. Experiment with the Simpler Player • Six video profiles between 0.7 and 5 Mbps • Bottleneck capacity 10 Mbps • Four players are competing Player-1 starts streaming Three more player join Two players leave

  26. Shaping Rate Decrease • During shaping the server distinguishes between oscillations • Due to OFF periods • Shaping rate should be decreased • Due to short-term avail-bw reductions • No reason to modify the shaping rate • How to distinguish between the two cases? • Based on the requested profiles in the last W chunks Short-term available bandwidth drops detected

  27. Shaping Rate Increase • The server occasionally estimates the available bandwidth • De-activates shaping for randomly chosen chunks • Measure the connection’s throughput by looking at the ratio cwnd/rtt • Increase the shaping rate if the estimated available bandwidth is higher than the shaping rate Two players leave Avail-bw increases Shaping rate increases Abort procedure activated

  28. Shaping Rate Increase

  29. Outline

  30. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Results • Performance metrics • Number of competing players • In the presence of a TCP bulk transfer • Mix of players • Conclusions

  31. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Results • Performance metrics • Number of competing players • In the presence of a TCP bulk transfer • Mix of players • Conclusions

  32. Performance Metrics • Instability • Fraction of successive chunks in which the requested bitrate is not constant • For each client: • Increase: 1, Decrease: -1, Constant: 0 • The number of 1’s and -1’s divided by the total number of chunk requests • Utilization • Aggregate throughput of all players divided by avail-bw

  33. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Results • Performance metrics • Number of competing players • In the presence of a TCP bulk transfer • Mix of players • Conclusions

  34. Number of Competing PlayersInstability • Unshaped players • Instability metric peaks at some mid-range N value • Shaped players • Instability metric significantly lower • We cannot reject the hypothesis that the mean instability is constant as N is increased

  35. Number of Competing PlayersUtilization • Between shaped and unshaped players • For some values of N, the utilization metric does not show a statistically significant difference • For other values of N, the difference in the actual utilization is not large

  36. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Results • Performance metrics • Number of competing players • In the presence of a TCP bulk transfer • Mix of players • Conclusions

  37. In the Presence of a TCP Bulk Transfer • Instability metric is much less in the shaped case • Aggregate utilization is high in both cases • The TCP flow tends to fill up the bottleneck • TCP connection takes up the largest share of the bottleneck’s capacity • BW=10 Mbps • 3 players • (shaped • or • unshaped) • Greedy

  38. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Results • Performance metrics • Number of competing players • In the presence of a TCP bulk transfer • Mix of players • Conclusions

  39. Mix of Players • Shaped players • have the lowest instability • Their presence helps to also stabilize the competing unshaped players • Utilization is slightly less in the mixed-player experiments • BW=12 Mbps • Two • shaped • and • two • unshaped • players

  40. Outline • Overview of adaptive streaming over HTTP • Multiple-player competition • Stabilization method and demonstration • Results • Conclusions

  41. Conclusions • Competition between adaptive streaming players can lead to performance problems • Instability, unfairnessand bandwidth underutilization • Root cause is the ON-OFF behavior of players during Steady-State • Players overestimate the fair share if their ON periods are not perfectly synchronized (which is rarely the case) • Traffic shaping can help mitigate instability • (Upon oscillations) by shaping chunks at a lower bitrate pushing players to switch to the lower profile • Without incurring significant loss in bandwidth utilization

More Related