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]