idnits 2.17.1 draft-rose-deen-ggie-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 26, 2016) is 2738 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-deen-daigle-ggie-01 == Outdated reference: A later version (-23) exists of draft-pantos-http-live-streaming-19 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Deen 3 Internet-Draft Comcast-NBCUniversal 4 Intended status: Informational W. Rose 5 Expires: April 29, 2017 WJR Consulting 6 October 26, 2016 8 GGIE Internet Video Use Cases 9 draft-rose-deen-ggie-use-cases-00 11 Abstract 13 This document describes the sets of Use Cases for the GGIE Glass to 14 Glass Internet Ecosystem. 16 This document is being discussed on the ggie@ietf.org mailing list. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 29, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. GGIE core elements . . . . . . . . . . . . . . . . . . . 3 54 1.1.1. Work reference . . . . . . . . . . . . . . . . . . . 3 55 1.1.2. Encode reference . . . . . . . . . . . . . . . . . . 3 56 1.1.3. MARS: Media Address Resolution Service . . . . . . . 4 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Basic Video Streaming . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Background: MPEG DASH and HLS Adaptive Bitrate Streaming 4 60 2.2. Adaptive Bitrate Streaming with GGIE . . . . . . . . . . 6 61 3. Extended Use Cases . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Privacy Protection with MEN Session Prefix . . . . . . . 6 63 3.2. Time Shifted Sharing of Shards . . . . . . . . . . . . . 6 64 3.3. Routing of MEN Prefix traffic to Caches . . . . . . . . . 7 65 3.4. Adaptive Cache Selection When Switching Networks . . . . 7 66 3.5. Equivalent MEN Substitution . . . . . . . . . . . . . . . 7 67 3.6. Smart Edge Caches . . . . . . . . . . . . . . . . . . . . 8 68 3.6.1. Automatic Response to Congestion and Failover . . . . 8 69 3.6.2. Miscellaneous Cache Abilities . . . . . . . . . . . . 8 70 3.7. Workflow Integration during Capture-Edit-Publish . . . . 8 71 4. Advanced Use Cases enabled by GGIE . . . . . . . . . . . . . 9 72 4.1. Adaptive MEN Selection When Switching Networks . . . . . 9 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 GGIE, the Glass to Glass Internet Ecosystem [I-D.deen-daigle-ggie] , 84 is an effort to improve video's use of the Internet though evolving 85 and applying modern Internet networking technology to Internet video. 86 This is in response to the current traffic volume and growth rate of 87 new traffic related to video. Seeking the largest possible impact, 88 GGIE is primarily focused on use cases such as streaming since these 89 by far account for the majority of Internet video traffic. 91 Recognizing that the technical elements introduced by GGIE to address 92 the high impact use cases might also have applicability to the many 93 other broader Internet video uses cases this document includes a 94 snapshot of other ways video uses the Internet so that the GGIE 95 elements can be evaluated and extended to apply to a broader set of 96 video Internet uses. 98 Finally a set of extended new use cases is documented illustrating 99 new Internet video capabilites enabled by GGIE that are either not 100 possible today, or which are made easier with GGIE. 102 The set of GGIE use cases is expected to expand in subsequent 103 versions of this draft. 105 1.1. GGIE core elements 107 GGIE's basic features are a standard way to refer to content at the 108 work level, assignment of an 128bit address to refer to an encoding 109 of a work, and the MARS mapping service to map between the two. 111 1.1.1. Work reference 113 The work level is how users tend to refer to a video. They focus on 114 the movie as a title versus the technical details such as the video 115 codec, resolution, or bitrate. An example is "I want to watch the 116 movie _Minions_". 118 The work level references are expressed as a URI 119 [I-D.daigle-deen-ggie-uri-snaptr] that holds the work identification 120 information from an external content identification system. 122 1.1.2. Encode reference 124 The encoding reference level refers to a particular encoding of a 125 video with a video codec. GGIE uses 128bit IPv6 addresses to refer 126 to encoded works. The IPv6 Prefix refers to the MEN (media encoding 127 network) for a specific encode of the work, while each full 128bit 128 address refers to the elements of the encoded work according to a MEN 129 for the particular packaging of the work. 131 Each instance of the same exact encoding has the same Prefix assigned 132 to it. This forms the basis for referring to the encoded work under 133 GGIE and enables the network through routing to direct a request to a 134 particular instance of the video shards in the MEN. Different 135 encodings, even those using the same codec, packaging, and bitrates 136 will have different Prefixes assigned to them so as to distinguish 137 them from one another. 139 The MEN scheme for MEPG DASH is documented in 140 [I-D.deen-naik-ggie-men-mpeg-dash] 142 1.1.3. MARS: Media Address Resolution Service 144 MARS performs the task of bidirectionally mapping work level 145 references to the IPv6 addresses assigned to encodings. 147 Work Reference URI 148 median:EIDR:10.5240%2F6933-25C9-299D-671A-24FB-V:example.com 149 | 150 | +--------+ 151 +---> + MARS +---> 2001:db8::/32 (MEN Prefix) 152 +--------+ 154 Figure 1: Media Address Resolution 156 1.2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119] . 162 2. Basic Video Streaming 164 2.1. Background: MPEG DASH and HLS Adaptive Bitrate Streaming 166 Video Streaming by far accounts most Internet video traffic with the 167 two leading methods being MPEG Dynamic Streaming over HTTP aka MPEG 168 DASH [DASH] and HTTP Live Streaming or HLS 169 [I-D.pantos-http-live-streaming]. HLS is used by Apple iOS and OS X 170 devices, and MPEG DASH is used on most non-Apple devices, and by some 171 applications that run across both Apple and non-Apple devices. 173 Both streaming methods follow the same basic use case of a player 174 pulling content from a server or cache across the network. Both work 175 at a high-level perspective by fragmenting the overall stream into 176 chunks (referred more generally in GGIE as shards) and then 177 transporting each chunk over a http or https connection. 179 Both support adaptive bitrate streaming by offering the same video 180 encoded at different bitrates and the ability to seamlessly switch 181 between bitrates during streamed playback. 183 Variable bitrate streaming with MPEG DASH 185 Player Server/Cache 186 http-get(DASH manifest) +---------------->| 187 | | 188 |<----------------+ return(DASH manifest) 189 process manifest + | 190 pick initial bitrate(br) + | 191 http-get(URL-br 1-chunk 1)+---------------->| 192 | | 193 |<----------------+ return(br 1-chunk 1) 194 decode and display chunk + | 195 evaluate br/choose next br+ | 196 http-get(url-br X-chunk 2) +---------------->| 197 |<----------------+ return(br X-chunk 2) 198 decode and display chunk + | 199 . . 200 . . 201 . . 202 evaluate br/choose next br+ | 203 http-get(url-br Y-chunk n) +---------------->| 204 |<----------------+ return(br Y-chunk n) 205 decode and display chunk + | 206 . . 207 continue until user stop/last chunk 209 where url-br X means URL to the X BitRate in the encoding 211 Figure 2: Simple MPEG DASH Streaming 213 HLS follows a similar flow using a M3U/M3U8 playlist instead of a 214 manifest. 216 In this simplified flow there is only a single server shown. In 217 practice, it is common to have the manifest direct the player to 218 caches that are close to the client in terms of the network distance, 219 and to direct the player to recommend bitrates based upon things such 220 as network performance telemetry known to the server as it creates 221 the manifest for the player. It is also common, but not shown above, 222 for the player to periodically request an updated manifest from the 223 server thus permitting the server to have the ability to provide 224 updated direction to the player. 226 The adaptive bitrate streaming is similar in concept for both MPEG 227 DASH and HLS with the player able to switch to different bitrates 228 based upon the network conditions it encounters, or because of 229 direction by the server sending updated manifests. 231 GGIE satisfies this basic use case as shown in the next section. 233 2.2. Adaptive Bitrate Streaming with GGIE 235 GGIE replaces the URLs in the Manifests/playlists that refer to 236 chunks/shards with IPv6 addresses following the MEN scheme 237 appropriate for their packaging such as MPEG DASH or HLS. Player 238 devices are able to play content without modification, but the use of 239 addresses to refer to shards permits the network to contribute to 240 transport optimizing by routing requests to the nearest cache 241 advertising the requested MEN prefix. 243 3. Extended Use Cases 245 3.1. Privacy Protection with MEN Session Prefix 247 Observation of the MEN addresses a player is requesting would permit 248 the observer to identify the video being streamed. One mitigation of 249 this is the use of an alternative MEN Prefix that is not persistently 250 associated with the video. for a player can use a session level MEN 251 Prefix that is not persistenly assigned to a MEN. A non-persistently 252 assigned MEN Prefix is substituted for the well known MEN of the 253 video encoding being streamed. 255 3.2. Time Shifted Sharing of Shards 257 This scenario involves two devices on the same local network segment 258 that are both streaming the same video but one devices is watching 259 the video time shifted from the other. For example, the first device 260 started playing the video 20 minutes ago, and the second device is 261 now starting playback from the beginning. 263 It would be a more efficient use of the downstream network if the 264 second device did not have to re-transport the same shards that the 265 first device already has retrieved from the upstream cache. The 266 optimal situation would be for any shards that have already been 267 retrieved by the first device to be locally made available to the 268 second device as it retrieves them instead of it doing a duplicate 269 retrieval from the upstream cache. The second device will then only 270 have to retrieve duplicate shards for those shards which are not 271 already locally available. For example, the shards from the start of 272 the video, through to when the second device began to stream the 273 video and the shards from the first device began to be retained and 274 made available to the second device. 276 If device 1 had already retrieved shards 1 through 99 with none of 277 the shards retained when device 2 begins viewing the video it will 278 have to retrieve shards 1 through 99 from the upstream cache. 279 However, if the shards after 99 retrieved by device 1 were stored 280 locally either on device 1, device 2, or a third device, then device 281 2 could use the local copies when it gets to the point of the video 282 after shard 99. 284 3.3. Routing of MEN Prefix traffic to Caches 286 Each cache that holds a copy of the same MEN (unique title, encoding, 287 etc.) of a video will respond to requests for the shard at each 288 address under the MEN Prefix. Routing of the request to MEN Prefix 289 to a cache advertising it done by the network. 291 3.4. Adaptive Cache Selection When Switching Networks 293 When a player switches the network it is connected to during a 294 streaming session the new network is able to direct the player away 295 from the cache used for the MEN instance in the old network to a new 296 cache by using the MEN Prefix to route the traffic to the new cache. 297 An example of such a network switch is a device which has switched 298 from WiFi to and LTE connection due to moving out of its WiFi signal 299 range. 301 Note: There is an advanced version of this use case where the player 302 can switch to a new MEN that is better optimized for the new 303 network's traffic type - such as mobile versus wired. 305 3.5. Equivalent MEN Substitution 307 One MEN that is equivalent, same content but different encode, can be 308 substituted for another MEN. This permits use of already cached MEN 309 to satisfy requests to for any MEN that is an equivalent of. 311 Equivalency is a complex feature of a MEN. A trivial equivalency 312 where the two MEN are the same video, encoded with the same CODEC, 313 and packaged the same, yet differ in the prefix assigned them. More 314 complex equivalencies involve MEN instances for the same video, but 315 with different CODECs or different DRM encryptions. The measure of 316 equivalency of two MEN is dependent on the ability of the player 317 device to use on in place of another. 319 Equivalency Examples 320 Example 1 Same video, MEN differ by resolution - one Standard 321 Definition, the other High Definition 323 Example 2 Same original video, MEN differ by an EDIT such as 324 addition or removal of a scene 326 Example 3 Same video, MEN differ by audio language tracks such as 327 only English audio for one, while the other has English 328 and French audio 330 Example 4 Same video, MEN differ by audio language tracks such as 331 only English audio for one, while the other has English 332 and French audio 334 3.6. Smart Edge Caches 336 3.6.1. Automatic Response to Congestion and Failover 338 User is streaming content when the connection to the cache fails or 339 becomes overloaded, the cache becomes oversubscribed, or a new cache 340 is located that is, for whatever reason, better optimized to deliver 341 the content to the end point. The network can automatically locate 342 and route shard requests to alternate cache(s) that have the same or 343 equivalent MEN. 345 3.6.2. Miscellaneous Cache Abilities 347 Additional caches with the same MEN can be provisioned at any time 348 and they will immediately be able to respond to requests. 350 A smart edge cache could potentially provision associated caches with 351 the same MEN in the event it detects that it is becoming overloaded. 353 3.7. Workflow Integration during Capture-Edit-Publish 355 During capture by a camera, the video is assigned a media identifier. 356 A media identifier is be assigned, for example, by the camera or by a 357 service the user has subscribed to. The media identifier can be used 358 to identify the captured video through the storage and editing 359 workflow cycle, the final edit can use the original identifier or can 360 be issued a new one. Like wise a local MEN Prefix can be assigned to 361 the encoding created by the camera, with each subsequent encoding 362 issued another adhoc local MEN prefix to identify the encoding/ 363 packaging. The final encoding is issued a MEN prefix that is 364 globablly routable. The final media idenfitier and MEN prefix are 365 published via MARS. 367 4. Advanced Use Cases enabled by GGIE 369 4.1. Adaptive MEN Selection When Switching Networks 371 This is an advanced extension to Section 3.4 when a player switches 372 the network it is connected to during a streaming session. The 373 player's streaming session can adaptively switch to a new MEN 374 instance with a codec optimized for the new network such as when 375 switching from a high bandwidth WiFi connection to a lower bandwidth 376 mobile network. 378 5. Acknowledgements 380 Contributors in the development of these uses cases include John 381 Brzozowski, Leslie Daigle, Gaurav Naik 383 6. IANA Considerations 385 None (yet). 387 7. Security Considerations 389 None (yet). 391 8. References 393 8.1. Normative References 395 [I-D.daigle-deen-ggie-uri-snaptr] 396 Daigle, L. and G. Deen, "Glass to Glass Internet Ecosystem 397 URI and S-NAPTR Use", draft-daigle-deen-ggie-uri-snaptr-00 398 (work in progress), October 2016. 400 [I-D.deen-daigle-ggie] 401 Deen, G. and L. Daigle, "Glass to Glass Internet Ecosysten 402 Introduction", draft-deen-daigle-ggie-01 (work in 403 progress), June 2016. 405 [I-D.deen-naik-ggie-men-mpeg-dash] 406 Deen, G., Naik, G., Brzozowski, J., Daigle, L., Rose, B., 407 and W. Townsley, "Using Media Encoding Networks to address 408 MPEG-DASH video", draft-deen-naik-ggie-men-mpeg-dash-00 409 (work in progress), July 2016. 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, 413 DOI 10.17487/RFC2119, March 1997, 414 . 416 8.2. Informative References 418 [DASH] ISO, "Dynamic adaptive streaming over HTTP (DASH) -- Part 419 1: Media presentation description and segment formats", 420 . 423 [I-D.pantos-http-live-streaming] 424 Pantos, R. and W. May, "HTTP Live Streaming", draft- 425 pantos-http-live-streaming-19 (work in progress), April 426 2016. 428 Authors' Addresses 430 Glenn Deen 431 Comcast-NBCUniversal 433 Email: rgd.ietf@gmail.com 435 Bill Rose 436 WJR Consulting 438 Email: brose@wjrconsulting.com