idnits 2.17.1 draft-wu-http-streaming-optimization-ps-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 274 has weird spacing: '... Encode the m...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2010) is 4933 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2326' is defined on line 912, but no explicit reference was found in the text == Unused Reference: 'RFC1945' is defined on line 918, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 921, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework-02' is defined on line 947, but no explicit reference was found in the text == Unused Reference: 'HTML5' is defined on line 950, but no explicit reference was found in the text == Unused Reference: 'ServerSentEvent' is defined on line 953, but no explicit reference was found in the text == Unused Reference: 'SmoothStreaming' is defined on line 961, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2326 (Obsoleted by RFC 7826) ** Downref: Normative reference to an Informational RFC: RFC 1945 == Outdated reference: A later version (-17) exists of draft-ietf-avt-rapid-acquisition-for-rtp-16 -- No information found for draft-ietf-pmol-metrics-framework-02 - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu 3 Internet-Draft R. Huang 4 Intended status: Standards Track Huawei 5 Expires: April 28, 2011 October 25, 2010 7 Problem Statement for HTTP Streaming 8 draft-wu-http-streaming-optimization-ps-03 10 Abstract 12 HTTP Streaming allows breaking the live contents or stored contents 13 into several chunks/fragments and supplying them in order to the 14 client. However streaming long duration and high quality media over 15 the internet to satisfy the real time streaming requirements has 16 several Challenges when we require the client to access the same 17 media content with the common Quality experience at any device, 18 anytime, anywhere. This document explores problems inherent in HTTP 19 streaming. Several issues regarding network support for HTTP 20 Streaming have been raised, which include QoE improvement offering to 21 streaming video over Internet, efficient delivery, Playback control 22 and real time streaming media synchronization support. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 28, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Architecture of HTTP Streaming System . . . . . . . . . . . . 6 73 3.1. Functions of Streaming Components . . . . . . . . . . . . 7 74 3.2. Functions of Distribution Components . . . . . . . . . . . 8 75 3.3. Functions of Client Components . . . . . . . . . . . . . . 8 76 4. Existing Work and Model . . . . . . . . . . . . . . . . . . . 8 77 4.1. Media Fragments URI . . . . . . . . . . . . . . . . . . . 8 78 4.2. Media Presentation Description . . . . . . . . . . . . . . 9 79 4.3. Playback Control on media fragments . . . . . . . . . . . 9 80 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9 81 4.5. Existing HTTP Streaming Model(Client Pull Model) . . . . . 10 82 5. Analysis of different use cases . . . . . . . . . . . . . . . 10 83 5.1. Live Streaming Media broadcast . . . . . . . . . . . . . . 10 84 5.2. "Multi-Screen" Service Delivery . . . . . . . . . . . . . 11 85 5.3. Content Publishing between Servers . . . . . . . . . . . . 12 86 6. Aspects of Problem . . . . . . . . . . . . . . . . . . . . . . 13 87 6.1. Inefficient Streaming Content Delivery . . . . . . . . . . 13 88 6.2. No QoE Guaranteed Support . . . . . . . . . . . . . . . . 14 89 6.3. No QoS Control and Feedback Support . . . . . . . . . . . 15 90 6.4. No Streaming Content Distribution and Discovery Support . 16 91 6.5. Lacking Streaming media Synchronization support . . . . . 16 92 6.6. No Multicast Support . . . . . . . . . . . . . . . . . . . 17 93 6.7. Inadequate Streaming Playback Control . . . . . . . . . . 17 94 7. Scope of the problem . . . . . . . . . . . . . . . . . . . . . 18 95 7.1. Enhanced HTTP Streaming Pull model . . . . . . . . . . . . 19 96 7.2. HTTP Streaming Push model . . . . . . . . . . . . . . . . 19 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 98 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 101 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 104 1. Introduction 106 Streaming service is described as transmission of data over network 107 as a steady continuous stream, allowing playback to proceed while 108 subsequent data is being received, which may utilize multiple 109 transport protocols for data delivery. HTTP streaming refers to the 110 streaming service wherein the HTTP protocol is used for basic 111 transport of media data. One example of HTTP streaming is 112 progressive download streaming which allows the user to access 113 content using existing infrastructure before the data transfer is 114 complete. 116 In recent years, HTTP streaming system has been widely used on the 117 Internet for the delivery of multimedia content. There are several 118 reasons for this industry trend, for example: 120 o Existing Media Streaming protocols often have difficulty getting 121 around firewalls because they are commonly based on UDP with 122 unusual port numbers. HTTP streaming has no such problems because 123 firewalls know to pass HTTP packets through well-known port 80. 125 o Due to the success of Web, both HTTP server and HTTP client are 126 quite common in industry, which means that building a HTTP based 127 media delivery system may have less cost compared to those using 128 dedicated media server/client and intermediaries. 130 In order to better support the streaming characteristics, such as 131 trick modes, adaptation to resolutions, some approaches have been 132 commonly adopted in current HTTP streaming systems. For example, 133 media segmentation method separates the whole media content to a 134 series of small chunks and supplies them to the client through a 135 sequence of HTTP responses. Segmentation allows the client to seek 136 to different piece of media content, change the bit-rate of the next- 137 to-fetch chunk, as well as enables reducing the overall transmission 138 delay in case that one TCP connection trying to resend the lost 139 packet before sending anything further. 141 With media segmentation support, existing HTTP streaming technology 142 (e.g., progressive download HTTP streaming) is characterized as: 144 o Client based pull schemes that is, the client firstly acquires a 145 manifest file containing the reference (e.g. URI) to each media 146 chunks from the streaming server, then requests the media chunks 147 by forming a sequence of HTTP request messages to the server. 148 This client based pull model more relies on client to handle 149 buffer and playback during download. 151 o Relying on existing web infrastructure, i.e., no special server 152 and intermediaries are required other than a standard HTTP Server 153 and HTTP caches/proxies. 155 However streaming long duration and high quality media over the 156 internet to offer TV experience at any device and satisfy the real 157 time streaming requirements faces several unique Challenges when 158 there are no network capabilities available for HTTP Streaming: 160 o In client pull model, there will be additional round trips between 161 the client and the server for manifest file update before the 162 client can request each new chunk, which could risk the real-time 163 feature of live streaming. 165 o Lack of QoE guarantee on the packet switching based Internet and 166 hard to offer better experience than TV viewing. Compared to the 167 dedicated IPTV system, the HTTP streaming based on the best-effort 168 Internet may suffer more from network transition. For example, 169 when a user switches live channel or start VoD, there is no 170 guarantee on startup time. 172 o Lack of Feedback on Quality of data delivery. e.g., there is no 173 streaming quality control mechanisms like RTCP to report QoE 174 metrics that are important to the HTTP streaming system for 175 control or diagnostic purpose. 177 o Lack of QoS Control. For example, there is no QoS difference 178 between high speed Internet traffic and Streaming over Internet 179 traffic and hard for QoS surcharges on consumer broadband 180 subscription. 182 o Lacking multicast support. 184 With these above challenges, the typical user experience with the 185 existing HTTP streaming schemes may be limited by unacceptable 186 latency and waiting time, better effort quality, buffering delays or 187 interruption, etc, and inadequate playback control, especially for 188 live broadcast. Therefore these existing streaming schemes is more 189 applicable to recorded contents viewing that offers a better 190 experience over slower connections for recorded contents viewer. 191 Especially, in the case of "Multi-Screen", the service provider 192 intends to provide a common user experience when the user enjoys the 193 media content across PCs, TVs, and smart-phones. Therefore, HTTP 194 streaming over the Internet without some optimization on network 195 transport for QoE improvement may lead difficulty for the service 196 provider to comply the service level agreements (SLAs) between 197 service provider and users. 199 This document explores problems inherent in HTTP streaming. Several 200 issues regarding network support for HTTP Streaming have been raised, 201 which include QoS improvement offering to streaming video over 202 Internet, efficient delivery, playback control and real time 203 streaming media synchronization support etc. The following sections 204 described architecture of HTTP streaming system, introduce related 205 works and model on HTTP streaming, analyze some use cases in HTTP 206 streaming and list the potential problems when providing better 207 streaming quality over the Internet. 209 2. Terminology 211 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [RFC2119]. 215 Push Model: The model that allows the server keep pushing data 216 packets to the client. 218 Pull Model: The model that allows the client keep pulling data 219 packets from the server. 221 Live Streaming: Live events can be streamed over the Internet with 222 the help of broadcast software which encodes the live source and 223 delivers the resulting stream to the server. The server then 224 transfers the stream. So the user experiences the event as it 225 happens. 227 On-Demand Streaming: To provide "anytime" access to media content, 228 client is allowed to select and playback on demand. 230 Progressive Download: A mode that allow client playback the media 231 file while the file is downloading, after only a few seconds wait 232 for buffering, the process of collecting the first part of a media 233 file before playing. 235 Adaptive Streaming: Adaptive streaming is a process that adjusts the 236 quality of a video delivered to a client based on the changing 237 network conditions to ensure the best possible viewer experience. 239 3. Architecture of HTTP Streaming System 241 Figure 1 shows reference Architecture for HTTP Streaming in general 242 case. The Architecture should comprise the following components: 244 +--Streaming--+ +-Distribution+ +- Client -+ 245 | Component | | Component | | Component | 246 | +-------+ | | +--------+ | | +------+ | 247 | | Media | | | | HTTP | | | | HTTP | | 248 | |Encoder| | | | Proxy/ | | | |Client| | 249 | +-------+ | | | Server | | | +------+ | 250 | +---------+ |------->| +--------+ |------>| | 251 | |Streaming| | | +-------+ | | | 252 | |Segmenter| |<-------| |Network| |<------|+---------+| 253 | +---------+ | | | Cache | | ||Streaming|| 254 | +------+ | | +-------+ | || Client || 255 | | HTTP | | | +---------+ | |+---------+| 256 | |Server| | | |Streaming| | | | 257 | +------+ | | | Engine | | +-----------+ 258 +-------------+ | +---------+ | 259 +-------------+ 261 Figure 1: Reference Architecture for HTTP Streaming 263 o Streaming Component 265 o Distribution Component 267 o Client Component 269 3.1. Functions of Streaming Components 271 +--------------------+----------------------------------------------+ 272 | Function | Role | 273 +--------------------+----------------------------------------------+ 274 | Media Encoder | Encode the media and encapsulate with | 275 | | specific streaming formats for delivery | 276 | - | - | 277 | Streaming | divide the input media into a series of small| 278 | Segementer | chunks;Create index file containing reference| 279 | | to each chunks | 280 | - | - | 281 | HTTP Server | handles HTTP request from client and respond | 282 | | to HTTP connections | 283 +--------------------+----------------------------------------------+ 285 Figure 2: Functions of Streaming Component 287 3.2. Functions of Distribution Components 289 +--------------------+----------------------------------------------+ 290 | Function | Role | 291 +--------------------+----------------------------------------------+ 292 | Network Cache | Cache the data | 293 | | | 294 | - | - | 295 | Streaming | Distinguish between regular HTTP traffic and | 296 | Engine | HTTP Streaming Traffic; Enable HTTP Streaming| 297 | | localized | 298 | - | - | 299 | HTTP Proxy/ | Handles HTTP request from client;Forward data| 300 | Server | to client or respond to HTTP connections | 301 +--------------------+----------------------------------------------+ 303 Figure 3: Functions of Distribution Component 305 3.3. Functions of Client Components 307 +--------------------+----------------------------------------------+ 308 | Function | Role | 309 +--------------------+----------------------------------------------+ 310 | Streaming | | 311 | Client | Handle Streaming Playout and Buffer | 312 | | | 313 | - | - | 314 | HTTP | Initialize HTTP Connection | 315 | Client | | 316 +--------------------+----------------------------------------------+ 318 Figure 4: Functions of Client Components 320 4. Existing Work and Model 322 Based on the architecture described in Section 3, a growing number of 323 works have been done to build HTTP streaming system with the intend 324 to provide more streaming characteristics such as URI for media 325 fragment, media presentation description, playback control etc. Also 326 how existing HTTP Streaming model(i.e., client pull model) has been 327 discussed. 329 4.1. Media Fragments URI 331 W3C Media Fragments Working Group extends URI defined in [RFC3986]and 332 specifies some new semantics of URI fragments and URI queries 333 [MediaFragments] which is used to identify media fragments. The 334 client can use such Media Fragments URI component to retrieve one 335 fragment following the previous fragment from the server. However 336 such component is not extensible to convey more important streaming 337 information about bandwidth utilization, quality control and buffer 338 management. Therefore it is a big challenge to use the existing web 339 infrastructure with such component to deliver streaming contents with 340 QoE guaranteed. 342 4.2. Media Presentation Description 344 [I.D-pantos-http-live-streaming]formerly defines media presentation 345 format by extending M3U Playlist files and defining additional flags. 346 3GPP TS 26.234 also centers around media presentation format and 347 specifies Semantics of Media presentation description for HTTP 348 Adaptive Streaming [TS26.234], which contains metadata required by 349 the client(i.e., Smartphone) to construct appropriate URIs 350 [RFC3986]to access segments and to provide the streaming service to 351 the user. We refer to this media presentation description as 352 playlist component. With such component support, client can poll the 353 new data in chunks one by one. However without client request using 354 HTTP, the server will not push the new data to the client, therefore 355 it may not meet the real-time requirements when streaming live media 356 to clients only relying on client poll model to deliver high quality 357 streaming contents across the best-effort Internet, especially when 358 experiencing network transition. More survey on MPD and client pull 359 model can be found in [GapAnalysis] 361 4.3. Playback Control on media fragments 363 W3C HTML5 Working Group has incorporated video playback features into 364 HTML5 Specification which we refer to as local playback control. 365 Such local playback capability has been previously dependent on 366 third-party browser plug-ins. Now HTML5 specification lifts video 367 playback out of the generic element and put it into 368 specialized