Internet DRAFT - draft-begen-webpush-dash-reqs
draft-begen-webpush-dash-reqs
Network Working Group A. Begen
Internet-Draft Cisco
Intended status: Informational K. Streeter
Expires: April 30, 2015 Adobe Systems Incorporated
I. Bouazizi
Samsung Research
F. Denoual
Canon Research Centre France
October 27, 2014
MPEG DASH Requirements for a webpush Protocol
draft-begen-webpush-dash-reqs-00
Abstract
This draft presents two of the ongoing core experiments for the
amendment of the MPEG Dynamic Adaptive Streaming over HTTP (DASH)
specification and discusses some requirements for a webpush protocol
in the context of these core experiments.
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 April 30, 2015.
Copyright Notice
Copyright (c) 2014 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
Begen, et al. Expires April 30, 2015 [Page 1]
Internet-Draft MPEG DASH Requirements October 2014
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
2. DASH Requirements in the Core Experiments . . . . . . . . . . 3
2.1. Requirements from the FDH CE . . . . . . . . . . . . . . 3
2.2. Requirements from the SAND CE . . . . . . . . . . . . . . 3
3. Guidance from the IETF . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Informative References . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
HTTP adaptive streaming (HAS) has become the technology of choice for
delivering video content over the Internet. HAS will play an
increasingly important role in delivering video to the primary and
secondary screens.
In HAS, streaming clients are offered multiple representations of the
same content. Clients independently choose a segment (i.e., a piece
of the content) belonging to a representation to fetch from the
content delivery network, a choice that is made at every switching
boundary (usually every 2-10 seconds). The choice is based on a
number of parameters, including the network throughput observed by
the client.
To date they have been several different HAS implementations from
different vendors. To achieve interoperability, MPEG has started
working on a specification in 2010 and published the first edition of
the Dynamic Adaptive Streaming over HTTP specification in 2012.
Earlier this year, the second edition has been published
[DASH-Part1].
To add new features and capabilities to the DASH applications, the
DASH subgroup is currently running a number of core experiments (CE)
[DASH-CE]. Two of these CEs are (i) DASH over Full Duplex HTTP-based
Protocols (FDH) and (ii) Server and Network Assisted DASH (SAND). In
these CEs, there is a need for a webpush protocol. This draft
discusses some requirements for a such protocol to be used in DASH
applications.
Begen, et al. Expires April 30, 2015 [Page 2]
Internet-Draft MPEG DASH Requirements October 2014
2. DASH Requirements in the Core Experiments
2.1. Requirements from the FDH CE
The FDH CE is investigating the problem of delivering media segments
with shorter delay and/or reducing the request processing on the HTTP
server. The technologies considered are HTTP/2 and WebSockets.
The main idea is that once a client is interested in streaming a
particular content (e.g., a live channel), it may be beneficial not
to send an individual GET request for each segment to the network.
The network may keep sending segments once they become available to
the client for a predetermined amount of time or until the client
tells the server to stop.
We realize that a content delivery network or an operator network can
consist of both HTTP/2 enabled servers and HTTP 1.1 servers as well
as proxy servers, some of which could have been implemented
improperly. An important requirement for us is that the push feature
should not cause any caching inconsistency or reduce caching
efficiency. Note that not all clients streaming the same content
will necessarily use the push feature. Some may continue fetching
each segment separately (the conventional way), some may ask for the
push of the next k segments from the server or some may ask for push
till a further command.
An important issue is to decide how the clients will be able to ask
for not one but multiple segments in a single GET request, i.e.,
specifying a list of segments or potentially a pattern that includes
wildcards or any other agreeable formats. At least two options are
considered: a modified URL scheme and the use of an extension header.
In both cases modifications are expected on the origin server and
possibly the cache servers (We will likely need a special handler on
the servers). We would like to get advice on any of these
technologies taking into account among others backward-compatibility,
efficiency, caching issues, processing load, extensibility and
likelihood of implementation.
The DASH clients may run in browsers, mobile applications, on
personal computers or other connected devices. Typically it cannot
be assumed that in all applications a DASH client will have access to
the HTTP stack in a given platform. Such constraints should be taken
into account when looking for a broadly acceptable and highly-
scalable solution.
2.2. Requirements from the SAND CE
Begen, et al. Expires April 30, 2015 [Page 3]
Internet-Draft MPEG DASH Requirements October 2014
The SAND CE has the goal of establishing a bi-directional messaging
plane between the clients and other so-called Dash-aware Network
Elements (DANE). The DANEs may also communicate with each other.
Common DANEs include proxies and caches as well as analytics servers
and other network devices. On the direction from a DANE to a DASH
client (or another DANE), the messages can carry any kind of
operational information and/or assistance information so that the
DASH client (or the DANE) can take a proper action. On the direction
from a DASH client to a DANE, the messages are expected to carry
metrics and status information.
A simple use case for sending an operational information to a DASH
client is to ask the client to switch to a particular CDN provider.
Another use case is to ask the DASH client to fetch a particular
representation, simply because that representation's segments are
already cached at the edge of the network. Yet other use cases may
include network status information such as bitrate guarantees,
delays, etc.
An obvious choice for the protocol to carry these SAND messages back
and forth is HTTP. The DASH clients can send their metrics and
status messages upon demand or periodically to a pre-designated
server. However, sending messages in the other direction (from a
DANE to a DASH client) may be more challenging since DASH clients may
or may not be expecting such a message. It is important to note that
we do not want to put time-sensitive client-specific feedback
messages on top of the HTTP responses containing non-time-critical
and non-client-specific media segments.
To enable bi-directional communication between a DASH client and a
DANE, we can also use WebSockets or the HTTP/2 PUSH technologies.
However, we consider a more lightweight protocol that will scale to
large populations when sending a common message or individual
messages.
3. Guidance from the IETF
We would like to ask the webpush WG to consider media delivery use
cases as part of the webpush activity, including the delivery of MPEG
DASH content. We also would like to ask the webpush WG to advise us
on best practices on using header and URL based signaling for push
behavior, and get feedback on proper message channels for SAND.
Begen, et al. Expires April 30, 2015 [Page 4]
Internet-Draft MPEG DASH Requirements October 2014
4. Security Considerations
There are no security considerations.
5. IANA Considerations
There are no IANA considerations.
6. Informative References
[DASH-Part1]
Available at: http://standards.iso.org/ittf/
PubliclyAvailableStandards/index.html, , "ISO/IEC
23009-1:2014: Dynamic adaptive streaming over HTTP (DASH)
-- Part 1: Media presentation description and segment
formats (2nd edition)", May 2014.
[DASH-CE] Available at: http://wg11.sc29.org/doc_end_user/
current_meeting_intermediate.php?id_meeting=162, ,
"Descriptions of core experiments on DASH amendment
(w14858)", Oct. 2014.
Authors' Addresses
Ali Begen
Cisco
181 Bay Street
Toronto, ON M5J 2T3
Canada
EMail: abegen@cisco.com
Kevin Streeter
Adobe Systems Incorporated
345 Park Avenue
San Jose, CA 95110
USA
EMail: kstreete@adobe.com
Begen, et al. Expires April 30, 2015 [Page 5]
Internet-Draft MPEG DASH Requirements October 2014
Imed Bouazizi
Samsung Research
1301 E. Lookout Dr.
Richardson, TX 75082
USA
EMail: i.bouazizi@sta.samsung.com
Franck Denoual
Canon Research Centre France
Rue de la Touche Lambert
Cesson-Sevigne 35517
France
EMail: franck.denoual@crf.canon.fr
Begen, et al. Expires April 30, 2015 [Page 6]
