Network Working Group Q. Wu Internet-Draft R. Huang Intended status: Standards Track Huawei Expires: April 28, 2011 October 25, 2010 Problem Statement for HTTP Streaming draft-wu-http-streaming-optimization-ps-03 Abstract HTTP Streaming allows breaking the live contents or stored contents into several chunks/fragments and supplying them in order to the client. However streaming long duration and high quality media over the internet to satisfy the real time streaming requirements has several Challenges when we require the client to access the same media content with the common Quality experience at any device, anytime, anywhere. This document explores problems inherent in HTTP streaming. Several issues regarding network support for HTTP Streaming have been raised, which include QoE improvement offering to streaming video over Internet, efficient delivery, Playback control and real time streaming media synchronization support. Status of this Memo 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 Internet-Draft will expire on April 28, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Wu & Huang Expires April 28, 2011 [Page 1] Internet-Draft HTTP Streaming Problem Statement October 2010 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Wu & Huang Expires April 28, 2011 [Page 2] Internet-Draft HTTP Streaming Problem Statement October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Architecture of HTTP Streaming System . . . . . . . . . . . . 6 3.1. Functions of Streaming Components . . . . . . . . . . . . 7 3.2. Functions of Distribution Components . . . . . . . . . . . 8 3.3. Functions of Client Components . . . . . . . . . . . . . . 8 4. Existing Work and Model . . . . . . . . . . . . . . . . . . . 8 4.1. Media Fragments URI . . . . . . . . . . . . . . . . . . . 8 4.2. Media Presentation Description . . . . . . . . . . . . . . 9 4.3. Playback Control on media fragments . . . . . . . . . . . 9 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Existing HTTP Streaming Model(Client Pull Model) . . . . . 10 5. Analysis of different use cases . . . . . . . . . . . . . . . 10 5.1. Live Streaming Media broadcast . . . . . . . . . . . . . . 10 5.2. "Multi-Screen" Service Delivery . . . . . . . . . . . . . 11 5.3. Content Publishing between Servers . . . . . . . . . . . . 12 6. Aspects of Problem . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Inefficient Streaming Content Delivery . . . . . . . . . . 13 6.2. No QoE Guaranteed Support . . . . . . . . . . . . . . . . 14 6.3. No QoS Control and Feedback Support . . . . . . . . . . . 15 6.4. No Streaming Content Distribution and Discovery Support . 16 6.5. Lacking Streaming media Synchronization support . . . . . 16 6.6. No Multicast Support . . . . . . . . . . . . . . . . . . . 17 6.7. Inadequate Streaming Playback Control . . . . . . . . . . 17 7. Scope of the problem . . . . . . . . . . . . . . . . . . . . . 18 7.1. Enhanced HTTP Streaming Pull model . . . . . . . . . . . . 19 7.2. HTTP Streaming Push model . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Wu & Huang Expires April 28, 2011 [Page 3] Internet-Draft HTTP Streaming Problem Statement October 2010 1. Introduction Streaming service is described as transmission of data over network as a steady continuous stream, allowing playback to proceed while subsequent data is being received, which may utilize multiple transport protocols for data delivery. HTTP streaming refers to the streaming service wherein the HTTP protocol is used for basic transport of media data. One example of HTTP streaming is progressive download streaming which allows the user to access content using existing infrastructure before the data transfer is complete. In recent years, HTTP streaming system has been widely used on the Internet for the delivery of multimedia content. There are several reasons for this industry trend, for example: o Existing Media Streaming protocols often have difficulty getting around firewalls because they are commonly based on UDP with unusual port numbers. HTTP streaming has no such problems because firewalls know to pass HTTP packets through well-known port 80. o Due to the success of Web, both HTTP server and HTTP client are quite common in industry, which means that building a HTTP based media delivery system may have less cost compared to those using dedicated media server/client and intermediaries. In order to better support the streaming characteristics, such as trick modes, adaptation to resolutions, some approaches have been commonly adopted in current HTTP streaming systems. For example, media segmentation method separates the whole media content to a series of small chunks and supplies them to the client through a sequence of HTTP responses. Segmentation allows the client to seek to different piece of media content, change the bit-rate of the next- to-fetch chunk, as well as enables reducing the overall transmission delay in case that one TCP connection trying to resend the lost packet before sending anything further. With media segmentation support, existing HTTP streaming technology (e.g., progressive download HTTP streaming) is characterized as: o Client based pull schemes that is, the client firstly acquires a manifest file containing the reference (e.g. URI) to each media chunks from the streaming server, then requests the media chunks by forming a sequence of HTTP request messages to the server. This client based pull model more relies on client to handle buffer and playback during download. Wu & Huang Expires April 28, 2011 [Page 4] Internet-Draft HTTP Streaming Problem Statement October 2010 o Relying on existing web infrastructure, i.e., no special server and intermediaries are required other than a standard HTTP Server and HTTP caches/proxies. However streaming long duration and high quality media over the internet to offer TV experience at any device and satisfy the real time streaming requirements faces several unique Challenges when there are no network capabilities available for HTTP Streaming: o In client pull model, there will be additional round trips between the client and the server for manifest file update before the client can request each new chunk, which could risk the real-time feature of live streaming. o Lack of QoE guarantee on the packet switching based Internet and hard to offer better experience than TV viewing. Compared to the dedicated IPTV system, the HTTP streaming based on the best-effort Internet may suffer more from network transition. For example, when a user switches live channel or start VoD, there is no guarantee on startup time. o Lack of Feedback on Quality of data delivery. e.g., there is no streaming quality control mechanisms like RTCP to report QoE metrics that are important to the HTTP streaming system for control or diagnostic purpose. o Lack of QoS Control. For example, there is no QoS difference between high speed Internet traffic and Streaming over Internet traffic and hard for QoS surcharges on consumer broadband subscription. o Lacking multicast support. With these above challenges, the typical user experience with the existing HTTP streaming schemes may be limited by unacceptable latency and waiting time, better effort quality, buffering delays or interruption, etc, and inadequate playback control, especially for live broadcast. Therefore these existing streaming schemes is more applicable to recorded contents viewing that offers a better experience over slower connections for recorded contents viewer. Especially, in the case of "Multi-Screen", the service provider intends to provide a common user experience when the user enjoys the media content across PCs, TVs, and smart-phones. Therefore, HTTP streaming over the Internet without some optimization on network transport for QoE improvement may lead difficulty for the service provider to comply the service level agreements (SLAs) between Wu & Huang Expires April 28, 2011 [Page 5] Internet-Draft HTTP Streaming Problem Statement October 2010 service provider and users. This document explores problems inherent in HTTP streaming. Several issues regarding network support for HTTP Streaming have been raised, which include QoS improvement offering to streaming video over Internet, efficient delivery, playback control and real time streaming media synchronization support etc. The following sections described architecture of HTTP streaming system, introduce related works and model on HTTP streaming, analyze some use cases in HTTP streaming and list the potential problems when providing better streaming quality over the Internet. 2. Terminology The keywords "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]. Push Model: The model that allows the server keep pushing data packets to the client. Pull Model: The model that allows the client keep pulling data packets from the server. Live Streaming: Live events can be streamed over the Internet with the help of broadcast software which encodes the live source and delivers the resulting stream to the server. The server then transfers the stream. So the user experiences the event as it happens. On-Demand Streaming: To provide "anytime" access to media content, client is allowed to select and playback on demand. Progressive Download: A mode that allow client playback the media file while the file is downloading, after only a few seconds wait for buffering, the process of collecting the first part of a media file before playing. Adaptive Streaming: Adaptive streaming is a process that adjusts the quality of a video delivered to a client based on the changing network conditions to ensure the best possible viewer experience. 3. Architecture of HTTP Streaming System Figure 1 shows reference Architecture for HTTP Streaming in general Wu & Huang Expires April 28, 2011 [Page 6] Internet-Draft HTTP Streaming Problem Statement October 2010 case. The Architecture should comprise the following components: +--Streaming--+ +-Distribution+ +- Client -+ | Component | | Component | | Component | | +-------+ | | +--------+ | | +------+ | | | Media | | | | HTTP | | | | HTTP | | | |Encoder| | | | Proxy/ | | | |Client| | | +-------+ | | | Server | | | +------+ | | +---------+ |------->| +--------+ |------>| | | |Streaming| | | +-------+ | | | | |Segmenter| |<-------| |Network| |<------|+---------+| | +---------+ | | | Cache | | ||Streaming|| | +------+ | | +-------+ | || Client || | | HTTP | | | +---------+ | |+---------+| | |Server| | | |Streaming| | | | | +------+ | | | Engine | | +-----------+ +-------------+ | +---------+ | +-------------+ Figure 1: Reference Architecture for HTTP Streaming o Streaming Component o Distribution Component o Client Component 3.1. Functions of Streaming Components +--------------------+----------------------------------------------+ | Function | Role | +--------------------+----------------------------------------------+ | Media Encoder | Encode the media and encapsulate with | | | specific streaming formats for delivery | | - | - | | Streaming | divide the input media into a series of small| | Segementer | chunks;Create index file containing reference| | | to each chunks | | - | - | | HTTP Server | handles HTTP request from client and respond | | | to HTTP connections | +--------------------+----------------------------------------------+ Figure 2: Functions of Streaming Component Wu & Huang Expires April 28, 2011 [Page 7] Internet-Draft HTTP Streaming Problem Statement October 2010 3.2. Functions of Distribution Components +--------------------+----------------------------------------------+ | Function | Role | +--------------------+----------------------------------------------+ | Network Cache | Cache the data | | | | | - | - | | Streaming | Distinguish between regular HTTP traffic and | | Engine | HTTP Streaming Traffic; Enable HTTP Streaming| | | localized | | - | - | | HTTP Proxy/ | Handles HTTP request from client;Forward data| | Server | to client or respond to HTTP connections | +--------------------+----------------------------------------------+ Figure 3: Functions of Distribution Component 3.3. Functions of Client Components +--------------------+----------------------------------------------+ | Function | Role | +--------------------+----------------------------------------------+ | Streaming | | | Client | Handle Streaming Playout and Buffer | | | | | - | - | | HTTP | Initialize HTTP Connection | | Client | | +--------------------+----------------------------------------------+ Figure 4: Functions of Client Components 4. Existing Work and Model Based on the architecture described in Section 3, a growing number of works have been done to build HTTP streaming system with the intend to provide more streaming characteristics such as URI for media fragment, media presentation description, playback control etc. Also how existing HTTP Streaming model(i.e., client pull model) has been discussed. 4.1. Media Fragments URI W3C Media Fragments Working Group extends URI defined in [RFC3986]and specifies some new semantics of URI fragments and URI queries [MediaFragments] which is used to identify media fragments. The Wu & Huang Expires April 28, 2011 [Page 8] Internet-Draft HTTP Streaming Problem Statement October 2010 client can use such Media Fragments URI component to retrieve one fragment following the previous fragment from the server. However such component is not extensible to convey more important streaming information about bandwidth utilization, quality control and buffer management. Therefore it is a big challenge to use the existing web infrastructure with such component to deliver streaming contents with QoE guaranteed. 4.2. Media Presentation Description [I.D-pantos-http-live-streaming]formerly defines media presentation format by extending M3U Playlist files and defining additional flags. 3GPP TS 26.234 also centers around media presentation format and specifies Semantics of Media presentation description for HTTP Adaptive Streaming [TS26.234], which contains metadata required by the client(i.e., Smartphone) to construct appropriate URIs [RFC3986]to access segments and to provide the streaming service to the user. We refer to this media presentation description as playlist component. With such component support, client can poll the new data in chunks one by one. However without client request using HTTP, the server will not push the new data to the client, therefore it may not meet the real-time requirements when streaming live media to clients only relying on client poll model to deliver high quality streaming contents across the best-effort Internet, especially when experiencing network transition. More survey on MPD and client pull model can be found in [GapAnalysis] 4.3. Playback Control on media fragments W3C HTML5 Working Group has incorporated video playback features into HTML5 Specification which we refer to as local playback control. Such local playback capability has been previously dependent on third-party browser plug-ins. Now HTML5 specification lifts video playback out of the generic element and put it into specialized