Internet DRAFT - draft-rose-deen-ggie-use-cases
draft-rose-deen-ggie-use-cases
Network Working Group G. Deen
Internet-Draft Comcast-NBCUniversal
Intended status: Informational W. Rose
Expires: April 29, 2017 WJR Consulting
October 26, 2016
GGIE Internet Video Use Cases
draft-rose-deen-ggie-use-cases-00
Abstract
This document describes the sets of Use Cases for the GGIE Glass to
Glass Internet Ecosystem.
This document is being discussed on the ggie@ietf.org mailing list.
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 29, 2017.
Copyright Notice
Copyright (c) 2016 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.
Deen & Rose Expires April 29, 2017 [Page 1]
Internet-Draft GGIE Use Cases October 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. GGIE core elements . . . . . . . . . . . . . . . . . . . 3
1.1.1. Work reference . . . . . . . . . . . . . . . . . . . 3
1.1.2. Encode reference . . . . . . . . . . . . . . . . . . 3
1.1.3. MARS: Media Address Resolution Service . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Basic Video Streaming . . . . . . . . . . . . . . . . . . . . 4
2.1. Background: MPEG DASH and HLS Adaptive Bitrate Streaming 4
2.2. Adaptive Bitrate Streaming with GGIE . . . . . . . . . . 6
3. Extended Use Cases . . . . . . . . . . . . . . . . . . . . . 6
3.1. Privacy Protection with MEN Session Prefix . . . . . . . 6
3.2. Time Shifted Sharing of Shards . . . . . . . . . . . . . 6
3.3. Routing of MEN Prefix traffic to Caches . . . . . . . . . 7
3.4. Adaptive Cache Selection When Switching Networks . . . . 7
3.5. Equivalent MEN Substitution . . . . . . . . . . . . . . . 7
3.6. Smart Edge Caches . . . . . . . . . . . . . . . . . . . . 8
3.6.1. Automatic Response to Congestion and Failover . . . . 8
3.6.2. Miscellaneous Cache Abilities . . . . . . . . . . . . 8
3.7. Workflow Integration during Capture-Edit-Publish . . . . 8
4. Advanced Use Cases enabled by GGIE . . . . . . . . . . . . . 9
4.1. Adaptive MEN Selection When Switching Networks . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
GGIE, the Glass to Glass Internet Ecosystem [I-D.deen-daigle-ggie] ,
is an effort to improve video's use of the Internet though evolving
and applying modern Internet networking technology to Internet video.
This is in response to the current traffic volume and growth rate of
new traffic related to video. Seeking the largest possible impact,
GGIE is primarily focused on use cases such as streaming since these
by far account for the majority of Internet video traffic.
Recognizing that the technical elements introduced by GGIE to address
the high impact use cases might also have applicability to the many
other broader Internet video uses cases this document includes a
snapshot of other ways video uses the Internet so that the GGIE
elements can be evaluated and extended to apply to a broader set of
video Internet uses.
Deen & Rose Expires April 29, 2017 [Page 2]
Internet-Draft GGIE Use Cases October 2016
Finally a set of extended new use cases is documented illustrating
new Internet video capabilites enabled by GGIE that are either not
possible today, or which are made easier with GGIE.
The set of GGIE use cases is expected to expand in subsequent
versions of this draft.
1.1. GGIE core elements
GGIE's basic features are a standard way to refer to content at the
work level, assignment of an 128bit address to refer to an encoding
of a work, and the MARS mapping service to map between the two.
1.1.1. Work reference
The work level is how users tend to refer to a video. They focus on
the movie as a title versus the technical details such as the video
codec, resolution, or bitrate. An example is "I want to watch the
movie _Minions_".
The work level references are expressed as a URI
[I-D.daigle-deen-ggie-uri-snaptr] that holds the work identification
information from an external content identification system.
1.1.2. Encode reference
The encoding reference level refers to a particular encoding of a
video with a video codec. GGIE uses 128bit IPv6 addresses to refer
to encoded works. The IPv6 Prefix refers to the MEN (media encoding
network) for a specific encode of the work, while each full 128bit
address refers to the elements of the encoded work according to a MEN
for the particular packaging of the work.
Each instance of the same exact encoding has the same Prefix assigned
to it. This forms the basis for referring to the encoded work under
GGIE and enables the network through routing to direct a request to a
particular instance of the video shards in the MEN. Different
encodings, even those using the same codec, packaging, and bitrates
will have different Prefixes assigned to them so as to distinguish
them from one another.
The MEN scheme for MEPG DASH is documented in
[I-D.deen-naik-ggie-men-mpeg-dash]
Deen & Rose Expires April 29, 2017 [Page 3]
Internet-Draft GGIE Use Cases October 2016
1.1.3. MARS: Media Address Resolution Service
MARS performs the task of bidirectionally mapping work level
references to the IPv6 addresses assigned to encodings.
Work Reference URI
median:EIDR:10.5240%2F6933-25C9-299D-671A-24FB-V:example.com
|
| +--------+
+---> + MARS +---> 2001:db8::/32 (MEN Prefix)
+--------+
Figure 1: Media Address Resolution
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] .
2. Basic Video Streaming
2.1. Background: MPEG DASH and HLS Adaptive Bitrate Streaming
Video Streaming by far accounts most Internet video traffic with the
two leading methods being MPEG Dynamic Streaming over HTTP aka MPEG
DASH [DASH] and HTTP Live Streaming or HLS
[I-D.pantos-http-live-streaming]. HLS is used by Apple iOS and OS X
devices, and MPEG DASH is used on most non-Apple devices, and by some
applications that run across both Apple and non-Apple devices.
Both streaming methods follow the same basic use case of a player
pulling content from a server or cache across the network. Both work
at a high-level perspective by fragmenting the overall stream into
chunks (referred more generally in GGIE as shards) and then
transporting each chunk over a http or https connection.
Both support adaptive bitrate streaming by offering the same video
encoded at different bitrates and the ability to seamlessly switch
between bitrates during streamed playback.
Deen & Rose Expires April 29, 2017 [Page 4]
Internet-Draft GGIE Use Cases October 2016
Variable bitrate streaming with MPEG DASH
Player Server/Cache
http-get(DASH manifest) +---------------->|
| |
|<----------------+ return(DASH manifest)
process manifest + |
pick initial bitrate(br) + |
http-get(URL-br 1-chunk 1)+---------------->|
| |
|<----------------+ return(br 1-chunk 1)
decode and display chunk + |
evaluate br/choose next br+ |
http-get(url-br X-chunk 2) +---------------->|
|<----------------+ return(br X-chunk 2)
decode and display chunk + |
. .
. .
. .
evaluate br/choose next br+ |
http-get(url-br Y-chunk n) +---------------->|
|<----------------+ return(br Y-chunk n)
decode and display chunk + |
. .
continue until user stop/last chunk
where url-br X means URL to the X BitRate in the encoding
Figure 2: Simple MPEG DASH Streaming
HLS follows a similar flow using a M3U/M3U8 playlist instead of a
manifest.
In this simplified flow there is only a single server shown. In
practice, it is common to have the manifest direct the player to
caches that are close to the client in terms of the network distance,
and to direct the player to recommend bitrates based upon things such
as network performance telemetry known to the server as it creates
the manifest for the player. It is also common, but not shown above,
for the player to periodically request an updated manifest from the
server thus permitting the server to have the ability to provide
updated direction to the player.
Deen & Rose Expires April 29, 2017 [Page 5]
Internet-Draft GGIE Use Cases October 2016
The adaptive bitrate streaming is similar in concept for both MPEG
DASH and HLS with the player able to switch to different bitrates
based upon the network conditions it encounters, or because of
direction by the server sending updated manifests.
GGIE satisfies this basic use case as shown in the next section.
2.2. Adaptive Bitrate Streaming with GGIE
GGIE replaces the URLs in the Manifests/playlists that refer to
chunks/shards with IPv6 addresses following the MEN scheme
appropriate for their packaging such as MPEG DASH or HLS. Player
devices are able to play content without modification, but the use of
addresses to refer to shards permits the network to contribute to
transport optimizing by routing requests to the nearest cache
advertising the requested MEN prefix.
3. Extended Use Cases
3.1. Privacy Protection with MEN Session Prefix
Observation of the MEN addresses a player is requesting would permit
the observer to identify the video being streamed. One mitigation of
this is the use of an alternative MEN Prefix that is not persistently
associated with the video. for a player can use a session level MEN
Prefix that is not persistenly assigned to a MEN. A non-persistently
assigned MEN Prefix is substituted for the well known MEN of the
video encoding being streamed.
3.2. Time Shifted Sharing of Shards
This scenario involves two devices on the same local network segment
that are both streaming the same video but one devices is watching
the video time shifted from the other. For example, the first device
started playing the video 20 minutes ago, and the second device is
now starting playback from the beginning.
It would be a more efficient use of the downstream network if the
second device did not have to re-transport the same shards that the
first device already has retrieved from the upstream cache. The
optimal situation would be for any shards that have already been
retrieved by the first device to be locally made available to the
second device as it retrieves them instead of it doing a duplicate
retrieval from the upstream cache. The second device will then only
have to retrieve duplicate shards for those shards which are not
already locally available. For example, the shards from the start of
the video, through to when the second device began to stream the
Deen & Rose Expires April 29, 2017 [Page 6]
Internet-Draft GGIE Use Cases October 2016
video and the shards from the first device began to be retained and
made available to the second device.
If device 1 had already retrieved shards 1 through 99 with none of
the shards retained when device 2 begins viewing the video it will
have to retrieve shards 1 through 99 from the upstream cache.
However, if the shards after 99 retrieved by device 1 were stored
locally either on device 1, device 2, or a third device, then device
2 could use the local copies when it gets to the point of the video
after shard 99.
3.3. Routing of MEN Prefix traffic to Caches
Each cache that holds a copy of the same MEN (unique title, encoding,
etc.) of a video will respond to requests for the shard at each
address under the MEN Prefix. Routing of the request to MEN Prefix
to a cache advertising it done by the network.
3.4. Adaptive Cache Selection When Switching Networks
When a player switches the network it is connected to during a
streaming session the new network is able to direct the player away
from the cache used for the MEN instance in the old network to a new
cache by using the MEN Prefix to route the traffic to the new cache.
An example of such a network switch is a device which has switched
from WiFi to and LTE connection due to moving out of its WiFi signal
range.
Note: There is an advanced version of this use case where the player
can switch to a new MEN that is better optimized for the new
network's traffic type - such as mobile versus wired.
3.5. Equivalent MEN Substitution
One MEN that is equivalent, same content but different encode, can be
substituted for another MEN. This permits use of already cached MEN
to satisfy requests to for any MEN that is an equivalent of.
Equivalency is a complex feature of a MEN. A trivial equivalency
where the two MEN are the same video, encoded with the same CODEC,
and packaged the same, yet differ in the prefix assigned them. More
complex equivalencies involve MEN instances for the same video, but
with different CODECs or different DRM encryptions. The measure of
equivalency of two MEN is dependent on the ability of the player
device to use on in place of another.
Equivalency Examples
Deen & Rose Expires April 29, 2017 [Page 7]
Internet-Draft GGIE Use Cases October 2016
Example 1 Same video, MEN differ by resolution - one Standard
Definition, the other High Definition
Example 2 Same original video, MEN differ by an EDIT such as
addition or removal of a scene
Example 3 Same video, MEN differ by audio language tracks such as
only English audio for one, while the other has English
and French audio
Example 4 Same video, MEN differ by audio language tracks such as
only English audio for one, while the other has English
and French audio
3.6. Smart Edge Caches
3.6.1. Automatic Response to Congestion and Failover
User is streaming content when the connection to the cache fails or
becomes overloaded, the cache becomes oversubscribed, or a new cache
is located that is, for whatever reason, better optimized to deliver
the content to the end point. The network can automatically locate
and route shard requests to alternate cache(s) that have the same or
equivalent MEN.
3.6.2. Miscellaneous Cache Abilities
Additional caches with the same MEN can be provisioned at any time
and they will immediately be able to respond to requests.
A smart edge cache could potentially provision associated caches with
the same MEN in the event it detects that it is becoming overloaded.
3.7. Workflow Integration during Capture-Edit-Publish
During capture by a camera, the video is assigned a media identifier.
A media identifier is be assigned, for example, by the camera or by a
service the user has subscribed to. The media identifier can be used
to identify the captured video through the storage and editing
workflow cycle, the final edit can use the original identifier or can
be issued a new one. Like wise a local MEN Prefix can be assigned to
the encoding created by the camera, with each subsequent encoding
issued another adhoc local MEN prefix to identify the encoding/
packaging. The final encoding is issued a MEN prefix that is
globablly routable. The final media idenfitier and MEN prefix are
published via MARS.
Deen & Rose Expires April 29, 2017 [Page 8]
Internet-Draft GGIE Use Cases October 2016
4. Advanced Use Cases enabled by GGIE
4.1. Adaptive MEN Selection When Switching Networks
This is an advanced extension to Section 3.4 when a player switches
the network it is connected to during a streaming session. The
player's streaming session can adaptively switch to a new MEN
instance with a codec optimized for the new network such as when
switching from a high bandwidth WiFi connection to a lower bandwidth
mobile network.
5. Acknowledgements
Contributors in the development of these uses cases include John
Brzozowski, Leslie Daigle, Gaurav Naik
6. IANA Considerations
None (yet).
7. Security Considerations
None (yet).
8. References
8.1. Normative References
[I-D.daigle-deen-ggie-uri-snaptr]
Daigle, L. and G. Deen, "Glass to Glass Internet Ecosystem
URI and S-NAPTR Use", draft-daigle-deen-ggie-uri-snaptr-00
(work in progress), October 2016.
[I-D.deen-daigle-ggie]
Deen, G. and L. Daigle, "Glass to Glass Internet Ecosysten
Introduction", draft-deen-daigle-ggie-01 (work in
progress), June 2016.
[I-D.deen-naik-ggie-men-mpeg-dash]
Deen, G., Naik, G., Brzozowski, J., Daigle, L., Rose, B.,
and W. Townsley, "Using Media Encoding Networks to address
MPEG-DASH video", draft-deen-naik-ggie-men-mpeg-dash-00
(work in progress), July 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Deen & Rose Expires April 29, 2017 [Page 9]
Internet-Draft GGIE Use Cases October 2016
8.2. Informative References
[DASH] ISO, "Dynamic adaptive streaming over HTTP (DASH) -- Part
1: Media presentation description and segment formats",
<http://www.iso.org/iso/home/store/catalogue_ics/
catalogue_detail_ics.htm?csnumber=65274>.
[I-D.pantos-http-live-streaming]
Pantos, R. and W. May, "HTTP Live Streaming", draft-
pantos-http-live-streaming-19 (work in progress), April
2016.
Authors' Addresses
Glenn Deen
Comcast-NBCUniversal
Email: rgd.ietf@gmail.com
Bill Rose
WJR Consulting
Email: brose@wjrconsulting.com
Deen & Rose Expires April 29, 2017 [Page 10]
