[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                         H. Ruellan
Internet-Draft                                            March 23, 2015
Intended status: Informational
Expires: September 24, 2015


                             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




Ruellan                Expires September 24, 2015               [Page 1]


Internet-Draft               DASH and HTTP2                   March 2015


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

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



Ruellan                Expires September 24, 2015               [Page 2]


Internet-Draft               DASH and HTTP2                   March 2015


   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.

   o  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"

   o  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.

   o  Using a list of URIs:






Ruellan                Expires September 24, 2015               [Page 3]


Internet-Draft               DASH and HTTP2                   March 2015


      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"

   o  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 }"

   o  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"




Ruellan                Expires September 24, 2015               [Page 4]


Internet-Draft               DASH and HTTP2                   March 2015


   o  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

   [DASH]     , "Dynamic adaptive streaming over HTTP (DASH)", ISO/IEC
              23009-1:2014, 2014.

   [I-D.ietf-httpbis-http2]
              Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
              Protocol version 2", draft-ietf-httpbis-http2-17 (work in
              progress), February 2015.

   [LowLatencyStreaming]
              Wei, S. and V. Swaminathan, "Low Latency Live Video
              Streaming over HTTP 2.0", NOSSDAV 2014, 2014.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
              6455, December 2011.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570, March 2012.

Author's Address

   Herve Ruellan

   Email: herve.ruellan@crf.canon.fr












Ruellan                Expires September 24, 2015               [Page 5]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/