dynamic adaptive streaming over http (dash) …jmarty/projects/gamingassessments/...dynamic adaptive...
TRANSCRIPT
Dynamic Adaptive Streaming over HTTP (DASH) Application Protocol : Modeling and Analysis
Dr. Jim Martin
Associate Professor
School of Computing
Clemson University
http://www.cs.clemson.edu/~jmarty
1Clemson University, School of Computing Web Site: http://www.clemson.edu/ces/computing/
Networks Research Group Website: http://www.cs.clemson.edu/~jmarty/netlab/
Executive Overview
2
• 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 HTTP-
based streaming is likely to be widely deployed.
Executive Overview
3
• But do you know ….
• What happens from the user’s perspective when
many DASH flows compete for limited
downstream bandwidth?
• What happens from a fairness perspective when
DASH flows compete with other TCP application
traffic?
• From an operator’s perspective, how does
DASH’s application level congestion control
behave when subject to service oriented
bandwidth management techniques such as
Sandvine’s Fairshare?
• How sensitive is the DASH client’s playback
buffer capacity setting on system performance?
Overview
4
•Background
•MPEG DASH
•Modeling of DASH
• Netflix empirical measurement
• Simulation model
•Example Simulation Results
•Open Issues
Background
5
•Let’s rewind a bit
• Video streaming has evolved from UDP-based streaming, to
TCP-based progressive downloading, to adaptive HTTP-
based streaming
•Several well established methods for adaptive HTTP streaming:
• Adobe’s HTTP Dynamic Streaming (HDS)
• Apple’s HTTP Live Streaming (HLS)
• Microsoft’s Smooth Streaming (SmoothHD)
•Will Law, Akamai's principal architect for media engineering,
commented, “We've spent the past five years delivering a variety of
adaptive video formats—SmoothHD, HLS and HDS—all of which are
80 percent the same but 100 percent incompatible.”
Background
6
•MPEG organization issued a Call for Proposal for an HTTP
Streaming Standard (2009).
•Resulting standard is MPEG-DASH over HTTP and has been
published as standard ISO/IEC 23009-1.
•The 3GPP community has been involved since 2009. 3GP-DASH is
in 3GPP standards TS 26.234 and 3GPP TS 26.244.
•The initiative has significant industry support….
• although not exactly clear about Apple or YouTube.
•Let’s fast forward a bit….
• DASH will make it easier for a content provider to build large
scale distribution systems that support the majority of client
device types.
• DASH is encoder/decoder agnostic. Content providers will
have to select the video encoding options and the range of
supported bit rates.
MPEG DASH
7
Figure from presentation at Streaming Media West “MPEG-DASH: Driving the Growth of Streaming Using the New HTTP Standard
(available online at http://www.streamingmedia.com/Conferences/West2011/docs/SMWest2011-MPEG-Dash.pdf )
MPEG DASH
8
Figure from presentation at Streaming Media West “MPEG-DASH: Driving the Growth of Streaming Using the New HTTP Standard
(available online at http://www.streamingmedia.com/Conferences/West2011/docs/SMWest2011-MPEG-Dash.pdf )
MPEG DASH
9
•A segment is an independent, viewable period of video/audio/timing
data..
• Segment sizes of 2 seconds or 10 seconds are reasonable.
•Segments are uniquely identified by an HTTP URL.
•A client requests the segment, the bit rate, and optionally a specific
byte range in the segment.
• Clients can issue requests and receive segments over any
number of concurrent TCP connections.
•The video segment is sent back by the HTTP server in a ‘burst’.
•The implementation of the client determines how frequently
segments are requested, when bit rate adaptation occurs, and the
overall ‘sensitivity’ of the application to network congestion.
Modeling DASH – Netflix Traces
10
InternetLinux Router
CentOS+
Netem
Xbox Netflix
NetflixClemson’s Network
Windows Netflix
CDN
Trace Point
(tcpdump)
Modeling DASH – Netflix Traces
11
Trace ID Netem Loss Setting Content Time of Day Client
1.1 none Accidental Spy 3/1/2012 21:20 Xbox
1.2 none Accidental Spy 3/1/2012 21:20 Windows
2.1 3% Independent Loss Accidental Spy 2/27/2012 16:42 Xbox
2.2 3% Independent Loss Accidental Spy 2/27/2012 16:42 Windows
3.1 Variable Loss Accidental Spy 2/24/2012 15:19 Xbox
3.2 Variable Loss Accidental Spy 2/25/2012 09:20 Windows
10.1 None Ns2 model Ns2 model
10.2 3% independent loss Ns2 Model Ns2 Model
10.3 Variable Loss Ns2 Model Ns2 Model
Each trace contains all TCP flows between the client and server that occur during the
first 60 minutes of the movie
Modeling DASH – Basic Behaviors
12
Buffering state
Steady state
Trace 1.2 - Netflix
Windows Client(no loss)
Visualizes the size of the playback buffer
Throughput Time Scale
1 seconds
5 seconds
Modeling DASH – Basic Behaviors
13
Trace 1.2 - Netflix Windows Client
(no loss)
Simulation Model
14
HTTP Server
DASH Client
Playback buffer queues segments
• clientbuffersize: Capacity in time,
• maxSegments: max queue size (segs)
• maxSize: max buffer size (bytes)
Representations
Player
Controller
HTTP Get Requests
{SegmentNumber,BitRate}
Segment data
Controller parameters
• Throughput Monitor Timescale
• Segment size in seconds
• Number of outstanding requests
Monitor Arrival Process
Rendering
Performance
updates
… …
Example Simulation Results
15
Trace 10.1 - ns2 model
(no loss)
Throughput Time Scale
1 seconds
5 seconds
Example Simulation Results
16
Trace 10.1 - ns2 model
(no loss)
Open Issues
17
• Back to our original questions:
• What happens from the user’s perspective when many
DASH flows compete for limited downstream bandwidth?
• What happens from a fairness perspective when DASH
flows compete with other TCP application traffic?
• From an operator’s perspective, how does DASH’s
application level congestion control behave when subject
to service oriented bandwidth management techniques
such as Sandvine’s Fairshare?
• How sensitive is the DASH client’s playback buffer
capacity setting on system performance?
Sounds like future work!!