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

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!!