Dynamic Adaptive Streaming over HTTP (DASH) Application Protocol : Modeling and Analysis

Transcription

1 Dynamic Adaptive Streaming over HTTP (DASH) Application Protocol : Modeling and Analysis Dr. Jim Martin Associate Professor School of Computing Clemson University jim.martin@cs.clemson.edu 1

2 Talk Overview Introduction Background Related work and problem formulation Methodology Results and analysis Conclusions Future work

3 Introduction We ve all heard about Netflix. We know Netflix consumes a significant portion of downstream bandwidth. We know that a standards-based approach for adaptive HTTPbased streaming is likely to be widely deployed. 3

4 Talk Overview Introduction Background Related work and problem formulation Methodology Results and analysis Conclusions Future work

5 5 Background

6 Throughput (Mbps) Background 7 TCP Cx second samples 1 second samples 3 Buffering state (37. Mbps between 1-3 seconds) Steady state (.39 Mbps) Throughput Time Scale 1 seconds 1 second

7 Background Simulation Model 7

8 Background Playback buffer capacity: This is configured in units of seconds. The client issues requests to maintain the playback buffer within an operating range defined by two internal parameters, Highwatermark and Lowwatermark. The default setting of the playback buffer capacity is 9 seconds. Number of outstanding client requests: This determines the maximum number of requests that can be outstanding at any given time. The default setting is segments. Segment size: This determines the granularity of the data exchanges between the DASH server and the client. The default is seconds. Adaptation Threshold: This tunes the client s sensitivity to changes in observed throughput. Discrete bitrate encoder options: The range of possible bitrate encoder values is set as follows (in units of bps) Bitrate Encoder Value Options: 7, 15,,, 3, 3,,

9 Talk Overview Introduction Background Related work and problem formulation Methodology Results and analysis Conclusions Future work 9

10 Related Work Standards [ISO11, 3GPP1] and basic overviews [STO11,SOD11] Basic assessments : [ABD11,AN11, LMT1, RLB11, KKH11] Improvements : [ACH1, CMP11, EKG11, LBG11, SSH11 Metrics : [OS1, DAJ11] Smartphone specifics : [NEE11A, NEE11B, XST9] Most recent provides insight in how multiple CDN s are used: Unreeling Netflix: Understanding and Improving Multi-CDN Movie Delivery 1

11 Problem Formulation We wanted to characterize the bandwidth consumption and behaviors of an early DASH implementation Are there differences across a range of client devices? Open questions are: How does application level control co-exist with TCP control? Does it give up too much bandwidth? Is it well behaved and stable during periods of volatile network conditions? What does an optimal design mean? What are the main design parameters at the client that impact an optimal design? 11

12 Talk Overview Introduction Background Related work and problem formulation Methodology Results and analysis Conclusions Future work 1

13 Methodology Measurement study - conduct controlled experiments using live Netflix sessions. Analyze tcpdump packet captures Simulation study - developed a simulation model of a DASH application in ns Used simulation to better understand empirical results Used simulation to better understand impact of the algorithms and design of the player 13

14 Measurement Testbed

15 Measurement Scenarios Scenario ID Description 1 Ideal with 3% artificial loss (5 minutes no impairment, 5 minutes 3% loss, 5 minutes no impairment) Ideal with % artificial loss (5 minutes no impairment, 5 minutes % loss, 5 minutes no impairment) 3 Stepped loss ( seconds at % loss, 1 seconds at 5% loss, 1 seconds at 1% loss, 1 seconds at % loss) Chaotic loss (3 seconds at % loss, 3 seconds at variable loss, 3 seconds at % loss) 5 Competing flows (5 minutes no competing TCP, 5 minutes with competing flow, last 5 minutes with no competing TCP) 5-1 : Xbox Wireless device, Downstream competing TCP 5- : Roku Wireless device, Downstream competing TCP 5-3 : Xbox Wireless device, Upstream competing TCP 5- : Roku Wireless device, Upstream competing TCP 15

16 1 Simulation Network Diagram Node 1 Netflix Servers router 1 Gbps or 1Mbps, 1Mbps,.5ms prop delay.5ms prop delay router GW Competing Traffic Generators/Sinks Data rates: 1 Gbps (US and DS) Node n

17 Simulation Scenarios Scenario ID Description 1 Ideal with 3% artificial loss (5 minutes no impairment, 5 minutes 3% loss, 5 minutes no impairment) Ideal with % artificial loss (5 minutes no impairment, 5 minutes % loss, 5 minutes no impairment) 3 Stepped loss ( seconds at % loss, 1 seconds at 5% loss, 1 seconds at 1% loss, 1 seconds at % loss Chaotic loss (3 seconds at % loss, 3 seconds at variable loss, 3 seconds at % loss) 5 A mix of netflix sessions and competing TCP flows over a wired network (no cable) A mix of netflix sessions and competing TCP flows over a cable network 17

18 Talk Overview Introduction Background Related work and problem formulation Methodology Results and analysis Conclusions Future work 1

19 Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Measurement Results second samples 5 second samples (.3,.33) (.95,.19) (.91,.71) a. Trace 1-1 (Xbox wired). second samples 5 second samples second samples 5 second samples c. Trace 1-3 (Xbox wifi) (.3,.39) (.71,.1) (3.11,.7) (.7,.5) (3.35,.1) (3.59,.7) (.,.1) (.,.17) (3.5,.). second samples 5 second samples b. Trace 1- (Windows wired) d. Trace 1- (Roku Wireless) second samples 5 second samples (.5,.5) (.5,.1) (3.55,.) Steady State Intervals 1: 5 3 seconds : 55 seconds 3: 75 9 seconds Results (in Mbps) : (mean bandwidth, standard deviation) e. Trace 1-5 (Android Wireless)

20 Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Measurement Results second samples 5 second samples second samples 5 second samples a. Trace -1 (Xbox wired) c. Trace -3 (Xbox wifi) 1. second samples 5 second samples 1. second samples 5 second samples b. Trace - (Windows wired) d. Trace - (Roku Wireless) 1 1. second samples 5 second samples e. Trace -5 (Android Wireless)

21 Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Measurement Results 1 1. second samples 5 second samples 1 1. second samples 5 second samples a. Trace 3-1 (Xbox wired) c. Trace 3-3 (Xbox wifi) 1 1. second samples 5 second samples 1 1. second samples 5 second samples b. Trace 3- (Windows wired) d. Trace 3- (Roku Wireless)

22 Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Bandwidth Consumption (Mbps) Measurement Results 1 1. second samples 5 second samples 1 1. second samples 5 second samples a. Trace -1 (Xbox wired) c. Trace -3 (Xbox wifi). second samples 5 second samples b. Trace - (Windows wired) d. Trace - (Roku Wireless) second samples 5 second samples

23 Throughput (Mbps) Throughput (Mbps) Throughput (Mbps) Throughput (Mbps) Throughput (Mbps) Throughput (Mbps) Throughput (Mbps) Throughput (Mbps) Throughput (Mbps) Throughput (Mbps) Measurement Results 1 TCP Cx 1. second samples 3 second samples 15 TCP Cx 1. second samples 3 second samples 1 TCP Cx 1 1 TCP Cx TCP Cx a. Trace 5-1 (Xbox Wireless, Downstream TCP) c. Trace 5- (Roku Wireless, Downstream TCP) 1 TCP Cx 1. second samples 3 second samples TCP Cx TCP Cx TCP Cx 1. second samples 3 second samples TCP Cx b. Trace 5-3 (Xbox Wireless, Upstream TCP) d. Trace 5- (Roku Wireless, Upstream TCP)

24 Measurement Results: Conclusions The basic response to network congestion is similar across the devices that were studied. However, the steady state bandwidth consumption achieved by different devices during periods of sustained congestion varied as did the details of how the client consumed available bandwidth following periods of congestion. The playback buffer sizes ranged from 3 seconds (on the Android WiFi device) to minutes (on the Windows Wired device). The size of the playback buffer is crucial in masking the effects of network congestion from the perceived quality.the average size of the client request ranged from 1. MB to 3.57 MB (we did not show these results in the paper). The Netflix adaptation appears to default to TCP control during periods of heavy, sustained network congestion. However, the application algorithm is clearly intertwined with TCP control during periods of volatile network conditions.

25 Simulation Results 5 Measurement Simulation

26 Simulation Results

27 7 Simulation Results

28 Simulation Results: Conclusions We see similar behaviors between measurement and simulation experiments. Some issues we are looking into: Max netflix rate in simulation. Mbps while measurement results show <. Mbps TCP throughput in simulation model (without Netflix) is lower than what we observe on Linux systems Confirmed fairness and expected behaviors when multiple flows competed for bandwidth

29 Talk Overview Introduction Background Related work and problem formulation Methodology Results and analysis Conclusions Future work 9

30 Conclusions and Next Steps 3 Saw similar basic behaviors across devices, but differences in details Further work to confirm if due to stack differences or Netflix implementation differences Netflix is very well behaved- aggressively drops bandwidth to below TCP fair levels. Perhaps too conservative in how it uses bandwidth that becomes available Very difficult to address the issue of is the adaptation doing the right thing without taking into account perceived quality Next steps User study Focus on fairness issues Focus on predicting future bandwidth Focus on enhancement to TCP that provides incentives for very well behaved applications