This document describes the sets of Use Cases for the GGIE Glass to Glass Internet Ecosystem.

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

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.

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.

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.

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.

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

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.

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