Liaison statement
Liaison Statement on the use of HTTP headers for DASH improvements

State Posted
Posted Date 2015-11-03
From Group ISO-IEC-JTC1-SC29-WG11
From Contact Shinji Watanabe
To Group IETF
To Contacts The IETF Chair
CcThe IESG
The IETF Chair
Stephan Wenger
Response Contact Watanabe Shinji
Purpose For information
Attachments (None)
Body
MPEG has defined the DASH standard for adaptive media streaming over HTTP.
Adaptation is achieved by offering several alternative Representations of the
content that are encoded at different bitrates or resolutions. The DASH client
can then select and switch between Representations based on its available
bandwidth. 

As part of DASH enhancements, MPEG is working on optimizing the media delivery
following two approaches:
-	Studying inter-working between DASH client and DASH aware HTTP proxies. 
-	Studying DASH over bi-directional protocols, in particular HTTP/2 and its
push feature.
Each approach makes use or defines HTTP header onto which MPEG would like to
receive feedbacks and guidelines from IETF.

For inter-working between DASH client and DASH aware HTTP proxies, one of the
DASH enhancement consists of a client indicating a list of representations
that it is willing to accept as an alternative response to the current
request. This is done through a new “Accept-Alternatives” header field
containing the URLs for each possibility.

In case an alternative representation of the resource is already cached, Vary
and Warning headers are added to change the identity of the response and
prevent it from being served as a response to a regular request. The
Content-Location header in the response indicates the URL of the actual
representation that was served (see example of use below).

We would like to kindly ask you the following:
•	Is this type of HTTP request/response conformant?
•	Are there any implications of such type of HTTP transactions (for example on
intermediate proxies)?
•	Are there alternatives provided by HTTP 1.1 to achieve similar results?

On the use of HTTP/2 push in DASH, MPEG is defining a set of messages that
allow clients to exchange push strategies with DASH servers (various
strategies are under consideration). For this, MPEG intends to define a new
Accept-Push-Policy header in order to convey the type of push strategy desired
by the client (see example below). The type of the push strategy is,
optionally followed by push-strategy-specific parameters. The syntax could
look like:

Accept-Push-Policy: <unique_name> [ ’;’ <policy-specific-param>*]

The message corresponding to the server response would optionally contain a
similar header enabling the server to acknowledge the strategy indicated by
the client. 
We’re interested in receiving feedback from IETF experts, in particular on the
following aspects:
•	Do IETF experts have recommendations and/or guidelines on “extending” the
list of HTTP Accept headers especially on exact syntax definition: recommended
separators, unique naming scheme, parameters passing
•	Should such header be defined at IETF level?


MPEG would appreciate your responses to any of the above-mentioned
questions.


Our future meetings:
-	The 114th MPEG meeting, 22 February 2015, San Diego
-	The 115th MPEG meeting, 30 May 2015, Geneva


Example of use for alternative response:
Let’s assume the DASH client selects the following as its normal request:
http://my.cdn.com/video/q_5/seg_25.mp4v
and it considers 2 alternative representations of the same video segment as
acceptable:
http://my.cdn.com/video/q_4/seg_25.mp4v
http://my.cdn.com/video/q_3/seg_25.mp4v
The http request from the DASH client would be:
 
[See document]

Example of use for push strategy exchange:
In live streaming scenario, a DASH client requesting a given media segment
(ex: segment_1.mp4) would like the server to push the 5 next segments in the
same Representation. Then, the client request would contain the new defined
header “accept-push-policy” with as value the push strategy type “push-next”
and as parameter the value for “5” next segments.
The header in the HTTP/2 HEADER frame would be:

[See document]