idnits 2.17.1 draft-deen-naik-ggie-men-mpeg-dash-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. 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 (July 7, 2016) is 2849 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: 1 error (**), 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 G. Naik 5 Expires: January 8, 2017 Drexel University 6 J. Brzozowski 7 Comcast 8 L. Daigle 9 Thinking Cat Enterprises LLC 10 W. Rose 11 WJR Consulting 12 M. Townsley 13 Cisco 14 July 7, 2016 16 Using Media Encoding Networks to address MPEG-DASH video 17 draft-deen-naik-ggie-men-mpeg-dash-00 19 Abstract 21 This document describes an approach to using a Media Encoding Network 22 of IPv6 Prefixes and Addresses as identifiers for MPEG-DASH encoded 23 video. This is part of the GGIE Glass to Glass Internet Ecosystem 24 effort for Internet Video. 26 This document is being discussed on the ggie@ietf.org mailing list. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 8, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2.1. Media Encoding Networks . . . . . . . . . . . . . . . . . 3 65 3. MPEG-DASH Internet Video Concepts . . . . . . . . . . . . . . 4 66 3.1. Internet Video playback as a network . . . . . . . . . . 4 67 4. MPEG-DASH Video Chunk Addressing . . . . . . . . . . . . . . 5 68 5. Video Playback . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Conclusion and Next Steps . . . . . . . . . . . . . . . . . . 7 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 11.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Introduction 87 GGIE, the Glass to Glass Internet Ecosystem, described in 88 [I-D.deen-daigle-ggie], is an effort to improve video's use of the 89 Internet though evolving and applying modern Internet networking 90 technology to Interet video. 92 This document is a proposed Media Encoding Network organizational 93 definition for MPEG-DASH enoded video. In the following sections, we 94 describe a Media Encoding Network structure for MPEG-DASH content 95 using IPv6 addresses as the address for MPEG-DASH video chunks, and 96 organizing these addresses into a IPv6 subnet under a prefix. 98 A MPEG-DASH encoded video organizaed following this Media Encoding 99 Network scheme is in turn referrable to using the assigned prefix, 100 with each distinct encoding of the video being assigned a distinct 101 prefix. Hence two copies of the same video encode would share the 102 same prefix, while a different encode would have a different prefix. 104 Other Media Encoding Networks organizational definitions are possible 105 for MPEG-DASH video. The simple organizational structure defined in 106 this document is designed to work, in a backwards compatible manner, 107 with existing MPEG-DASH video players. 109 2.1. Media Encoding Networks 111 One of the concepts being discussed in GGIE is that of a Media 112 Encoding Network. As introduced in the GGIE Introduction 113 [I-D.deen-daigle-ggie] document, a Media Encoding Network consists of 114 the data elements of a audio-video encoding of a work organized 115 following a distinct logical structure appropriate for efficiently 116 transporting and accessing the data elements for the video asset. 117 Network level identifiers are assigned to each of these elements 118 under a shared prefix and following an address assigment plan 119 appropropriate for the type of encoding used for the AV data. 121 Media Encoding Networks is a generalized abstraction intented to be 122 used with many different enoding and transport schemes. 124 GGIE recognizes that there is currently a great diversity of encoding 125 and transports such as MPEG-DASH [DASH] and HTTP Live Streaming (HLS) 126 [I-D.pantos-http-live-streaming] to name but two, with more 127 continuing to be developed and introduced. Recognizing this 128 diversity and innovative environment, GGIE proposes the Media 129 Encoding Network as a resuable abstraction that can be trailored and 130 defined with different logical organizations to support different 131 environments, applications, and media encodings. 133 A Media Encoding Network is a logical entity that can be assigned a 134 network level identifier enabling it to be referred to at a network 135 device level and permitting devices and the network to worked 136 cooperatively to optimize data transport and access choices. 138 3. MPEG-DASH Internet Video Concepts 140 A common technique used in the delivery of a media or video on the 141 Internet via streaming services and CDNs is to break up an encoding 142 of a video into chunks or media segments containing a fixed duration 143 of video. MPEG-DASH [DASH] is an example of such an approach. The 144 segments typically represent small portions of the video with 6-10 145 seconds of video playback being common. In most implementations, the 146 segments of videos are identified by file names and served to clients 147 using conventional web servers using HTTP GET requests. 149 Systems such as MPEG-DASH enable client players to switch between 150 encodings of different quality levels of the video with higher 151 quality encodings requiring large amounts of data, and conversely 152 lower quality encodings requiring smaller amounts of data. The 153 system coordinates each encoding to produce points of alignment 154 called intra-coded frames or iFrames where a player can switch 155 between different encodings without missing frames of the video 156 playback. Thus, a player can adapt to changing network conditions 157 without re-buffering or freezing of the playback. 159 When the encodings are broken into segments, the segments are 160 organized such that the playback system can switch to a different 161 encoding level from the version it has been playing by requesting the 162 next segment of data holding the iFrame matching the next iFrame of 163 the current encoding. In practice each segment of an encoding is an 164 individual file stored on video or CDN server and playback consists 165 of the player repeatedly requesting the next file in sequence from 166 the server, with the file names following a consistent incremental 167 naming scheme indicating an encoding identifier and a segment 168 sequence identifier. 170 Typically, a video file is processed by an encoder to produce two or 171 more different quality encodings with each encoded version being 172 passed through a process to break into segment files with aligned 173 iFrames and each file named with a name identifying the encoding and 174 sequence number. This process requires coordination to create iFrame 175 alignments and a consistent naming convention to allow players to 176 transition between encodings and to iteratively access the next 177 correct segment. 179 3.1. Internet Video playback as a network 181 Transitioning between segments is an example of a simple directed 182 graph (or digraph). Each segment is a vertex or node and the naming 183 convention defines an ordered directed traversal of the graph, and 184 the iFrame aligned segments forming the edges of the graph. It is 185 also possible to recognize that the directed graph behavior of a 186 player switching between segments can more generally be viewed as a 187 network such as it is used on the Internet. 189 The network of segments can be identified using the IP addressing 190 scheme from the Internet, in particular IPv6 is well suited for this 191 due to the large number of addresses available in it's 128-bit 192 address space. IPv4 could also be used, but with only 32 bits of 193 address space the available addresses would be quickly exhausted in 194 practical use. 196 This is really a simple evolution of the way MPEG-DASH chunks are 197 organized today as files with names such as MOVIE-SEGMENT-00, MOVIE- 198 SEGMENT-01,... and so on. In practical terms, this scheme simply 199 replaces the ASCII filename, with a 128-bit number represented as HEX 200 digits. In this way, this scheme remains compatible with existing 201 CDN serving of MPEG-DASH video. 203 4. MPEG-DASH Video Chunk Addressing 205 Staying consistent with Media Encoding Networks being a generic 206 abstraction, the more generic term Shard is used in place of the 207 MPEG-DASH specific Chunk for individual units of encoded video data. 209 IPv6 addresses [RFC4291] are specified in and are broken into two 210 parts that split the available 128 bits of address space as follows: 212 n bits 128-n bits 213 +--------------+----------------+ 214 | Prefix | Interface id | 215 +--------------+----------------+ 217 Figure 1: IPv6 Address 219 One addressing approach to naming segments can be as follows: 221 n bits m bits 128-n-m bits 222 +--------------------+-----------------+-------------+ 223 | Encoding Prefix | Sub-Encoding id | Shard id | 224 +--------------------+-----------------+-------------+ 226 Figure 2: Proposed 228 Which consists of an Encoding Prefix that is uniquely assigned to a 229 set of aligned MPEG-DASH encodings of the video, a sub-encoding id 230 which identifies a particular encoding, and the id of the individual 231 shard of encoded video data. 233 The encoding prefix permits a set of encodings to be associated with 234 one another. Grouping a set of encodings of a video under a shared 235 Encoding Prefix permits referencing all the segments of a group of 236 encodings as a single entity under the Encoding Prefix. 238 The sub-encoding id groups the shards of a single sub-encoding 239 together under an identifier to permit managing the collection of 240 segments as a single entity. 242 Shards that share MPEG iFrame aligment share the same Shard id. This 243 then defines a network layout with shards for each different bit-rate 244 organized sequentially and contiguously under a shared sub-encoding 245 subnet and shards with aligned iFrames being organized with the same 246 shard id across sub-encoding subnets. 248 5. Video Playback 250 This approach permits the Prefix to identify a particular group of 251 encodings of a video. Each encoding has an assigned series of 252 addresses consisting of the prefix, followed by the series of address 253 bits that uniquely identify the shard. All the playback pathways are 254 preserved in this addressing scheme of the edges of the graph. 256 The above approach works well for a video that is encoded by one 257 party that can coordinate the encoding process, to produce aligned 258 iFrames, and assign the common encoding prefix and segment 259 assignments for the network. 261 A playback device can be provided the Prefix for the network, and can 262 iterate through the segments to play the video. It can jump between 263 sub-encode subnets to select different quality or vary the bit rate 264 of the playback. 266 6. Implementation 268 For the evaluation of this scheme, a prototype video streaming 269 service implementing this approach was developed. In particular, it 270 provides an Electronic Program Guide (EPG) and uses an open-source 271 HTML5 video player with MPEG-DASH. Instead of providing the player 272 with HTTP URIs for each segment of video, our this prototype uses 273 global IPv6 addresses. This change is transparent to the host 274 operating system, the HTML5 video player, and the network. The 275 service backend is implemented in Python and utilizes other open 276 source components. A demonstration at IETF96 is planned to be shown 277 during Bits-n-Bytes. 279 7. Conclusion and Next Steps 281 This draft proposes a Media Encoding Network addressing scheme for 282 MPEG-DASH Internet video using IPv6 addresses. It is an example that 283 can built upon to define other more complex Media Encoding Network 284 schemes for MPEG-DASH and other encoding/transports. 286 8. Acknowledgements 288 9. IANA Considerations 290 None (yet). 292 10. Security Considerations 294 None (yet). 296 11. References 298 11.1. Normative References 300 [I-D.deen-daigle-ggie] 301 Deen, G. and L. Daigle, "Glass to Glass Internet Ecosysten 302 Introduction", draft-deen-daigle-ggie-01 (work in 303 progress), June 2016. 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 311 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 312 2006, . 314 11.2. Informative References 316 [DASH] ISO, "Dynamic adaptive streaming over HTTP (DASH) -- Part 317 1: Media presentation description and segment formats", 318 . 321 [I-D.pantos-http-live-streaming] 322 Pantos, R. and W. May, "HTTP Live Streaming", draft- 323 pantos-http-live-streaming-19 (work in progress), April 324 2016. 326 Authors' Addresses 328 Glenn Deen 329 Comcast-NBCUniversal 331 Email: rgd.ietf@gmail.com 333 Gaurav Naik 334 Drexel University 336 Email: gn@drexel.edu 338 John Jason Brzozowski 339 Comcast 341 Email: John_Brzozowski@Cable.Comcast.com 343 Leslie Daigle 344 Thinking Cat Enterprises LLC 346 Email: ldaigle@thinkingcat.com 348 Bill Rose 349 WJR Consulting 351 Email: brose@wjrconsulting.com 353 Mark Townsley 354 Cisco 355 Paris 357 Email: townsley@cisco.com