idnits 2.17.1 draft-begen-webpush-dash-reqs-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 date (October 27, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Begen 3 Internet-Draft Cisco 4 Intended status: Informational K. Streeter 5 Expires: April 30, 2015 Adobe Systems Incorporated 6 I. Bouazizi 7 Samsung Research 8 F. Denoual 9 Canon Research Centre France 10 October 27, 2014 12 MPEG DASH Requirements for a webpush Protocol 13 draft-begen-webpush-dash-reqs-00 15 Abstract 17 This draft presents two of the ongoing core experiments for the 18 amendment of the MPEG Dynamic Adaptive Streaming over HTTP (DASH) 19 specification and discusses some requirements for a webpush protocol 20 in the context of these core experiments. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 30, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. DASH Requirements in the Core Experiments . . . . . . . . . . 3 58 2.1. Requirements from the FDH CE . . . . . . . . . . . . . . 3 59 2.2. Requirements from the SAND CE . . . . . . . . . . . . . . 3 60 3. Guidance from the IETF . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6. Informative References . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 HTTP adaptive streaming (HAS) has become the technology of choice for 69 delivering video content over the Internet. HAS will play an 70 increasingly important role in delivering video to the primary and 71 secondary screens. 73 In HAS, streaming clients are offered multiple representations of the 74 same content. Clients independently choose a segment (i.e., a piece 75 of the content) belonging to a representation to fetch from the 76 content delivery network, a choice that is made at every switching 77 boundary (usually every 2-10 seconds). The choice is based on a 78 number of parameters, including the network throughput observed by 79 the client. 81 To date they have been several different HAS implementations from 82 different vendors. To achieve interoperability, MPEG has started 83 working on a specification in 2010 and published the first edition of 84 the Dynamic Adaptive Streaming over HTTP specification in 2012. 85 Earlier this year, the second edition has been published 86 [DASH-Part1]. 88 To add new features and capabilities to the DASH applications, the 89 DASH subgroup is currently running a number of core experiments (CE) 90 [DASH-CE]. Two of these CEs are (i) DASH over Full Duplex HTTP-based 91 Protocols (FDH) and (ii) Server and Network Assisted DASH (SAND). In 92 these CEs, there is a need for a webpush protocol. This draft 93 discusses some requirements for a such protocol to be used in DASH 94 applications. 96 2. DASH Requirements in the Core Experiments 98 2.1. Requirements from the FDH CE 100 The FDH CE is investigating the problem of delivering media segments 101 with shorter delay and/or reducing the request processing on the HTTP 102 server. The technologies considered are HTTP/2 and WebSockets. 104 The main idea is that once a client is interested in streaming a 105 particular content (e.g., a live channel), it may be beneficial not 106 to send an individual GET request for each segment to the network. 107 The network may keep sending segments once they become available to 108 the client for a predetermined amount of time or until the client 109 tells the server to stop. 111 We realize that a content delivery network or an operator network can 112 consist of both HTTP/2 enabled servers and HTTP 1.1 servers as well 113 as proxy servers, some of which could have been implemented 114 improperly. An important requirement for us is that the push feature 115 should not cause any caching inconsistency or reduce caching 116 efficiency. Note that not all clients streaming the same content 117 will necessarily use the push feature. Some may continue fetching 118 each segment separately (the conventional way), some may ask for the 119 push of the next k segments from the server or some may ask for push 120 till a further command. 122 An important issue is to decide how the clients will be able to ask 123 for not one but multiple segments in a single GET request, i.e., 124 specifying a list of segments or potentially a pattern that includes 125 wildcards or any other agreeable formats. At least two options are 126 considered: a modified URL scheme and the use of an extension header. 127 In both cases modifications are expected on the origin server and 128 possibly the cache servers (We will likely need a special handler on 129 the servers). We would like to get advice on any of these 130 technologies taking into account among others backward-compatibility, 131 efficiency, caching issues, processing load, extensibility and 132 likelihood of implementation. 134 The DASH clients may run in browsers, mobile applications, on 135 personal computers or other connected devices. Typically it cannot 136 be assumed that in all applications a DASH client will have access to 137 the HTTP stack in a given platform. Such constraints should be taken 138 into account when looking for a broadly acceptable and highly- 139 scalable solution. 141 2.2. Requirements from the SAND CE 142 The SAND CE has the goal of establishing a bi-directional messaging 143 plane between the clients and other so-called Dash-aware Network 144 Elements (DANE). The DANEs may also communicate with each other. 145 Common DANEs include proxies and caches as well as analytics servers 146 and other network devices. On the direction from a DANE to a DASH 147 client (or another DANE), the messages can carry any kind of 148 operational information and/or assistance information so that the 149 DASH client (or the DANE) can take a proper action. On the direction 150 from a DASH client to a DANE, the messages are expected to carry 151 metrics and status information. 153 A simple use case for sending an operational information to a DASH 154 client is to ask the client to switch to a particular CDN provider. 155 Another use case is to ask the DASH client to fetch a particular 156 representation, simply because that representation's segments are 157 already cached at the edge of the network. Yet other use cases may 158 include network status information such as bitrate guarantees, 159 delays, etc. 161 An obvious choice for the protocol to carry these SAND messages back 162 and forth is HTTP. The DASH clients can send their metrics and 163 status messages upon demand or periodically to a pre-designated 164 server. However, sending messages in the other direction (from a 165 DANE to a DASH client) may be more challenging since DASH clients may 166 or may not be expecting such a message. It is important to note that 167 we do not want to put time-sensitive client-specific feedback 168 messages on top of the HTTP responses containing non-time-critical 169 and non-client-specific media segments. 171 To enable bi-directional communication between a DASH client and a 172 DANE, we can also use WebSockets or the HTTP/2 PUSH technologies. 173 However, we consider a more lightweight protocol that will scale to 174 large populations when sending a common message or individual 175 messages. 177 3. Guidance from the IETF 179 We would like to ask the webpush WG to consider media delivery use 180 cases as part of the webpush activity, including the delivery of MPEG 181 DASH content. We also would like to ask the webpush WG to advise us 182 on best practices on using header and URL based signaling for push 183 behavior, and get feedback on proper message channels for SAND. 185 4. Security Considerations 187 There are no security considerations. 189 5. IANA Considerations 191 There are no IANA considerations. 193 6. Informative References 195 [DASH-Part1] 196 Available at: http://standards.iso.org/ittf/ 197 PubliclyAvailableStandards/index.html, , "ISO/IEC 198 23009-1:2014: Dynamic adaptive streaming over HTTP (DASH) 199 -- Part 1: Media presentation description and segment 200 formats (2nd edition)", May 2014. 202 [DASH-CE] Available at: http://wg11.sc29.org/doc_end_user/ 203 current_meeting_intermediate.php?id_meeting=162, , 204 "Descriptions of core experiments on DASH amendment 205 (w14858)", Oct. 2014. 207 Authors' Addresses 209 Ali Begen 210 Cisco 211 181 Bay Street 212 Toronto, ON M5J 2T3 213 Canada 215 EMail: abegen@cisco.com 217 Kevin Streeter 218 Adobe Systems Incorporated 219 345 Park Avenue 220 San Jose, CA 95110 221 USA 223 EMail: kstreete@adobe.com 224 Imed Bouazizi 225 Samsung Research 226 1301 E. Lookout Dr. 227 Richardson, TX 75082 228 USA 230 EMail: i.bouazizi@sta.samsung.com 232 Franck Denoual 233 Canon Research Centre France 234 Rue de la Touche Lambert 235 Cesson-Sevigne 35517 236 France 238 EMail: franck.denoual@crf.canon.fr