DASH and HTTP2
draft-ruellan-httpbis-dash-http2-00

Abstract

This document describes possibilities for DASH to take advantage of HTTP/2 features, in particular of server push.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 24, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Using Push with DASH
• 2.1. Live Video Latency
• 2.2. FDH Proposal
• 2.3. Other Proposals
• 3. Informative References
• Author's Address

1. Introduction

MPEG Dynamic Adaptive Streaming over HTTP (DASH [DASH]) is an adaptive bit-rate HTTP-based streaming solution standardized under MPEG. In DASH, a media is split into segments. Each segment of the media is encoded with different bit-rates to provide adaptation possibilities.

The client controls the streaming and the adaptation. To play the media, the client requests the segments one after the other, when needing them. For each segment, it can select the most appropriate bit-rate.

DASH defines a format for describing a media, the Media Presentation Description (MPD). The MPD contains information about the media, in particular the list of segments making up the media, and the different available bit-rates. DASH also defines formats for the media segments themselves.

The Full-Duplex HTTP based Protocols (FDH) is a Core Experiment inside MPEG for studying bi-directional communication protocols, such as HTTP/2 [I-D.ietf-httpbis-http2] and WebSocket [RFC6455], in the context of DASH. Inside this Core Experiments, the usage of the new features of HTTP/2 for DASH is investigated. Among these features, server push is attracting much interest.

2. Using Push with DASH

2.1. Live Video Latency

When using DASH for streaming a live video, there are some trade-off to make for choosing the duration of a segment. Shorter segments enable a lower latency, which is of importance for live video. However shorter segments also induce a larger number of requests, which can negatively impact the network performances.

In [LowLatencyStreaming], a solution to this problem is proposed: the live video is split into short segments. However, for each segment requested by the client, the server not only sends the corresponding segment, but also pushes some of the following segments. This enables to use a low latency while still keeping a low number of requests, therefore not incurring any negative impact on the network.

To let the client keep the control of the streaming, the client selects the number k of segments the server should push and transmit it to the server in its request. This strategy of segment transmission is therefore called k-push.

2.2. FDH Proposal

The FDH Core Experiment has built upon this k-push strategy for taking advantage of the push feature of HTTP/2, while letting the client control the streaming.

This Core Experiment is defining a new HTTP header field, named DASH-PUSH, that enables the client to indicate what it would like the server to push.

The DASH-PUSH header field contains parameters defining the strategy proposed by the client for indicating which segments it would like the server to push. Currently two strategies are defined.

• Pushing next K segments:
  
  The K segments following the requested segment are pushed by the server. For example, for having the server push the next 5 segments, the following header field is used:
  
  DASH-PUSH: type=push-next; K=5
• Pushing for T seconds:
  
  The segments corresponding to the given duration following the requested segment are pushed by the server. For example for having the server push the segments corresponding to the next 10 seconds of the media, the following header field is used:
  
  DASH-PUSH: type=type=push-time; T=10

2.3. Other Proposals

The DASH-PUSH header field can be extended for increasing its expressiveness.

• Using a list of URIs:
  
  All the resources listed are pushed by the server. For example, for having the server push the media segments seg-1.mp4, seg-2.mp4, and seg-3.mp4, the following header field is used:
  
  DASH-PUSH: type=uri-list; seg-1.mp4; seg-2.mp4; seg-3.mp4
• Using a URI template:
  
  Instead of listing all the URIs of the resources to push, a URI Template [RFC6570] can be used. The URI Template can use numbered variables whose values are defined as parameters of the DASH-PUSH header. These variable can have a single value, a list of values, or a range of values. For a variable with several values, the URI Template is expanded for each value of the variable.
  
  For example, for having the server push the same media segments as in the previous example, using a URI Template with a variable defined as a list of values, the following header field is used:
  
  DASH-PUSH: type=uri-template; seg-{1}.mp4; 1 : 2 : 3
  
  Note that the values in the list are separated with colons.
  
  The same example can also use a range of values instead of a list, with the following header field:
  
  DASH-PUSH: type=uri-template; seg-{1}.mp4; { 1 - 3 }
  
  Several variables can also be used inside the URI Template, in this case, the URI Template is expanded for each combination of values for the defined variables. For example, to have the server push several media segments, numbered 1 to 3, each with two different representation levels, R1 and R2, the following header field is used:
  
  DASH-PUSH: type=uri-template; seg-rep-{1}-{2}.mp4; R1 : R2; { 1 - 3 }
• Using a URI wildcard:
  
  Instead of specifying a list of URIs, a wildcard can be used, allowing to have the server push all the resources corresponding to a given media type. For example, for having the server push all the text/css resources linked to the requested resource, the following header field is used:
  
  DASH-PUSH: type=uri-wildcard; text/css
• Header field value:
  
  The DASH-PUSH header field is not restricted to target only URIs, but can also be used to target other header fields, in defining the resources the client would like the server to push. For example, for having the server push different ranges of the requested resource, the following header field is used:
  
  DASH-PUSH: type=header; Range; 501-1000; 1001-1500
  
  This usage is similar to the list of URIs, but targeting specific header fields. It could be extended to support templates.

3. Informative References

Author's Address