Networking Working Group Q.Wu Internet Draft Huawei Intended status: Informational July 5, 2010 Expires: January 2011 HTTP streaming optimization Problem Statement draft-wu-http-streaming-optimization-ps-00.txt Abstract HTTP Streaming allows breaking the live contents or stored contents into several chunks/fragments and supplying them in order to the client. Several issues regarding control over the delivery of data with real-time property using HTTP have been raised. Also various issues arise when we consider offering the video quality requirements to streaming video over Internet. This document describes these issues. Status of this Memo This Internet-Draft is submitted to IETF 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 December 5, 2010. 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 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 Wu Expires January 5, 2011 [Page 1] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 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. Table of Contents 1. Introduction.................................................3 2. Terminology and Concept......................................4 3. Scope and Existing Work......................................4 3.1. Media Fragmenting.......................................5 3.2. Media Presentation......................................5 3.3. Command Control on Content Delivery.....................5 3.4. Rate Adaptation.........................................5 3.5. Fast cache..............................................6 4. Why HTTP Streaming...........................................6 5. Applicability Statement......................................6 6. System Overview..............................................7 6.1. Encoder.................................................7 6.2. HTTP Streaming Server...................................8 6.3. Distribution Server (HTTP Cache)........................8 6.4. HTTP Streaming Client...................................8 7. Deployment Scenarios for HTTP Streaming Optimization.........8 7.1. HTTP Streaming Push model without Distribution........... Server involvement......................................8 7.2. HTTP Streaming Pull model without Distribution........... Server involvement......................................9 7.3. HTTP Streaming Push model with Distribution.............. Server involvement......................................9 7.4. HTTP Streaming Pull model with Distribution.............. Server involvement.....................................10 8. HTTP Streaming Optimization Problem statement...............10 8.1. Streaming Content Encoding.............................10 8.2. Streaming Content Transmission.........................12 8.3. Streaming Playback Control and navigation..............12 8.4. Streaming Monitoring and Feedback......................13 8.5. Streaming Content Protection...........................14 Wu Expires January 5, 2011 [Page 2] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 8.6. Streaming Timing Control and Synchronization...........14 8.6.1. Timing control in the Push model..................14 8.6.2. Timing control in the Pull model..................15 8.7. Streaming Session State Control........................15 9. Analysis of different use cases.............................16 9.1. Content Publishing.....................................16 9.2. "Multi-Screen" Video Delivery..........................16 9.3. Time Shifted Playback..................................17 10. Security Consideration.....................................17 11. References.................................................17 11.1. Normative References..................................17 11.2. Informative References................................18 1. Introduction Streaming contents over Internet allows multiple transport protocols being used for data delivery. For example, the Real Time Streaming Protocol (RTSP) is making the transmission of data even more efficient than other previous protocols and ideal for video broadcasting since they place a high priority on continuous streaming rather than on other factors. However, the biggest issue with RTSP is that the protocol or its ports may be blocked by routers or firewall settings, preventing a device from accessing the stream. In contrast to RTSP transmission, HTTP is more widely supported in content distribution networks and does not depend on any special sever rather than standard HTTP Sever, which is more generally available than for RTSP. Also HTTP is generally accessible and allowed to traverse firewall using TCP port 80, which can facilitate optimizing HTTP delivery. As the standard protocol for the Web, HTTP is originally designed to reliably transfer text documents, email, executable programs, and HTML web pages over the Internet while enforcing maximum reliability and data integrity rather than timeliness. However, when HTTP is used to transmit the streaming contents relying on time-based operation, it is much more likely to cause major packet drop-outs due to TCP based retransmission for packet loss, and it cannot deliver nearly the same amount of streams as RTSP transmission. Another issue is when viewing stored contents on the Internet, the huge video file may take long time to download before it could play which usually cause long and perhaps unacceptable delays. Current download-and-play client always download the entire video file and play back the video file. Wu Expires January 5, 2011 [Page 3] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 These issues can be addressed by breaking the live contents or stored contents into several chunks/fragments and supplying them in order to the client. In such case, the media content can be received and rendered simultaneously, the end user can start watching the contents almost as soon as it begins downloading and parts of the content are being received and decoded. We also can refer to this as HTTP streaming. When streaming clients start playing video or audio, due to real time nature of contents, the server should decide how to tune the video encoder algorithm to satisfy the video quality requirements (e.g., bandwidth, layered video codec, delay and loss requirements) and determine which mechanism to use in a given situation and when to switch to another mechanism as system parameters change. Unfortunately the current best-effort Internet does not offer any QoS guarantees to streaming video over Internet. This document explores problem inherent in HTTP streaming support. Several issues regarding control over the delivery of data with real- time property using HTTP have been raised. Also various issues arise when we consider offering QoS guarantee and Security to streaming video over Internet. The following section defines the scope of this document, describes related work, lists the symptoms and then the underlying problems. 2. Terminology and Concept The key words "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]. Pull model: The model that allows the server keep pushing data packets to the client. Push model: The model that allows the client keep pulling data packets from the server. 3. Scope and Existing Work Although the majority of media traffic on the Internet is delivered via downloading and P2P technologies, streaming service is superior in handling thousands of concurrent streams simultaneously, e.g., flexible responses to network congestion, efficient bandwidth utilization, and high quality performance. This section describes existing related work and defines the scope of the problem. Wu Expires January 5, 2011 [Page 4] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 3.1. Media Fragmenting Media Fragments 1.0 specification [Media Fragments] specifies the syntax for constructing media fragment URIs and explains how to handle them when used over the HTTP protocol. It aims at enhancing the Web infrastructure for supporting the addressing and retrieval of subparts of time-based Web resources. 3.2. Media Presentation 3GPP TS 26.234 specifies Semantics of Media presentation description for HTTP Adaptive Streaming [TS 26.234], which contains metadata required by the client to construct appropriate URIs to access segments and to provide the streaming service to the user. [I.D- pantos-http-live-streaming] also defines media presentation format by extending M3U Playlist files and defining additional flags. This multimedia presentation is specified by URI [RFC3986] to a playlist file, which is an ordered list of media URIs and informational tags. Each media URI refers to a media file which is a segment of a single contiguous stream. 3.3. Command Control on Content Delivery The prevailing streaming protocols on the Internet are RTSP [RFC2326] and MMS [MMS]. In RTSP streaming, the client and the server exchange streaming command via RTSP, running on TCP. The media data packets and streaming control/feedback packets are delivered via RTP/RTCP or RDT [RDT]. In MMS streaming, all streaming commands and control packets between a client and a server are exchanged via MMS in the same TCP connection and the media data can be delivered over UDP or TCP. For both RTSP and MMS streaming, when TCP is used to deliver media data, the media and control packets are interleaved with RTSP or MMS commands in a single TCP connection, instead of using two separate TCP connections. In addition to RTSP and MMS, media can also be streamed through HTTP. Different from HTTP downloading, HTTP streaming uses the HTTP protocol to deliver both RTSP commands and media data. In Microsoft HTTP streaming, the RTSP header are embedded in the pragama header of HTTP messages. In RealNetworks and QuickTime HTTP streaming, the RTSP commands are embedded in HTTP message bodies with the base64 encoding format. 3.4. Rate Adaptation In order to adapt to bandwidth fluctuation, major media services such as Windows media and RealNetworks media support three kinds of techniques for rate adaptation. Stream switch enables a server to dynamically switch among streams with different encoding rates for Wu Expires January 5, 2011 [Page 5] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 the same object, based on the available network bandwidth, e.g., MBR encoding [MBR].This techniques is called "Intelligent Streaming" in the Windows media service and "SureStream" in the RealNetworks media service. However the rate adaptation functionality of MBR is poorly utilized, particularly when Fast Streaming is used. Streaming Thinning enables a server to only send key frames to the client, when no lower bit rate stream is available. If the current bandwidth is not sufficient to transmit key frames, a server can only send audio to client, which is called video cancellation. 3GPP TS 26.234 also specifies the protocol for rate adaptation. However how the transmission and content rate are controlled for HTTP streaming is not specified yet. 3.5. Fast cache In practice, the play-out buffer may be exhausted since the available bandwidth between a client and its server may fluctuate from time to time. In order to provides a high quality streaming experience, Fast cache transmit media data to a client at a higher rate than media encoding rate [Fast Streaming], which can be used to smooth bandwidth fluctuation. However, fast cache may produce extra traffic, when the user stop in the middle of playback and pre-arrival data for the remaining part is cached. Also the server may be overloaded when the server consume more CPU, memory, disk I/O and other resources. 4. Why HTTP Streaming TBC. 5. Applicability Statement Wu Expires January 5, 2011 [Page 6] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 HTTP Streaming can be used on TCP port 80 or 8080, and traffic to that port is usually allowed through by firewalls, therefore, HTTP Streaming optimization mechanism can be applied if the client is behind a firewall that only allows HTTP traffic. HTTP Streaming may also be appropriate if the client sends feedback to the server that may cause the multimedia data that is being transmitted to change or cause the transmission rate to change. Furthermore, HTTP Streaming may be appropriate if the client must perform "trick-mode operations" on the multimedia data and prefers the server to execute trick modes on its behalf. The term "trick-mode operation" refers to operations like fast-forwarding and rewinding the data, pausing the transmission, or seeking a different position in the multimedia data stream. 6. System Overview +---------+ | Encoder | +----+----+ | | | | +-----V-----+ +--------------+ +-----------+ | HTTP |------>| Distribution |------>| HTTP | | Streaming | | Server | | Streaming | | Server |<------| (HTTP Cache) |<------| Client | +-----------+ +--------------+ +-----------+ Figure 1: Reference Architecture for HTTP Streaming Figure 1 shows reference Architecture for HTTP Streaming. The Architecture should comprise the following entities: 6.1. Encoder Encoder is the entity that Prepares Streaming Contents for transmission. It can be used to takes in live source feeds and encodes them into smooth streaming formats. Encoder may be collocated with HTTP Streaming Server, also may be separated from HTTP Streaming Server. If Encoder is separated from HTTP Streaming Server, it uses HTTP to send the streams to the HTTP Streaming Server. Wu Expires January 5, 2011 [Page 7] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 6.2. HTTP Streaming Server HTTP Streaming Server the entity that responds to the HTTP Connection. It ingests streams from Encoder, maintains all the information for the live streaming, handles Client requests. 6.3. Distribution Server (HTTP Cache) The distribution server is the entity located between HTTP Streaming Server and Client. It is used to offload streams using Caches and client requesting serving from HTTP Streaming Server. Also the distribution server can be used to facilitate forwarding the streams or pulling streams from the HTTP streaming server to the client. 6.4. HTTP Streaming Client HTTP Streaming Client is the entity that initiates the HTTP connection. It is used to issue fragment request and receive the streams from the server. 7. Deployment Scenarios for HTTP Streaming Optimization The deployment scenarios are outlined in the following sections. The following scenarios are discussed for understanding the overall problems of HTTP streaming contents delivery. In the HTTP Streaming, although the initial request and the commands are always coming from the client, we just focus on the data delivery part. Different model can be defined depending on whether: o The Distribution Server is not involved in HTTP Streaming o Who initiates data delivery 7.1. HTTP Streaming Push model without Distribution Server involvement In this case, data exchange happens between HTTP Streaming Server and HTTP Streaming Client. Distribution Server does not involve in this process. Streaming Content flows from the server to the Client. The server keeps pushing the latest data packets to the client and the client just passively receives everything. Therefore we also refer to it as push mode HTTP streaming. Wu Expires January 5, 2011 [Page 8] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 +-----------+ +-----------+ | HTTP | Push | HTTP | | Streaming |----------------------------->| Streaming | | Server | HTTP Streaming | Client | +-----------+ +-----------+ Figure 2: Push model for HTTP Streaming 7.2. HTTP Streaming Pull model without Distribution Server involvement As before, data exchanges between HTTP Streaming Server and HTTP Streaming Client. Distribution Server does not involve in this process. However, in this scenario, the Client pulls the fragment one after another by issuing fragment requests, one for each fragment. Then the server needs to either reply with data immediately or fail the request. +-----------+ Pull +-----------+ | HTTP |<-----------------------------| HTTP | | Streaming | HTTP Streaming | Streaming | | Server |----------------------------->| Client | +-----------+ +-----------+ Figure 3: Pull model for HTTP Streaming 7.3. HTTP Streaming Push model with Distribution Server involvement In this case, data exchanges between HTTP Streaming Server, Distribution Server and HTTP Streaming Client. Distribution Server with HTTP Cache Support is located between HTTP Streaming Server and HTTP Streaming Client and needs to involve in this process. The HTTP Streaming Server keeps pushing the latest data packets to the client, in the meanwhile, the HTTP Streaming server also push the data packets to the distribution server for caching. When the new client requests the same data packets as the one pushed to the previous client by the server and the data packets requested is cached on the distribution server, the distribution server can terminate this request on behalf of the HTTP Streaming server and push the requested data cached on itself to this new client. Wu Expires January 5, 2011 [Page 9] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 +-----------+ +--------------+ +-----------+ | HTTP | | Distribution | | HTTP | | Streaming | | Server | | Streaming | | Server | | (HTTP Cache) | | Client | +-----------+ +--------------+ +-----------+ Push ------------------------------> Push HTTP Streaming -------> HTTP Request <+++++++ Push --------> Figure 4: Push model for HTTP Streaming 7.4. HTTP Streaming Pull model with Distribution Server involvement As before, data exchanges between HTTP Streaming Server, Distribution Server and HTTP Streaming Client. The Distribution Server has HTTP Cache support. However, in this scenario, the client issues the fragment request to the Distribution Server or HTTP Streaming Server. Distribution Server may process the fragment Request on behalf of HTTP Streaming Server, when the fragment is not cached on the distribution server, the distribution server may fail this request. In the meanwhile, pulls this fragment from the HTTP Streaming Server and caches the data in itself and wait for the subsequent new request for this fragment from the clients. +-----------+ +--------------+ +-----------+ | HTTP | | Distribution | | HTTP | | Streaming | | Server | | Streaming | | Server | | (HTTP Cache) | | Client | +-----------+ +--------------+ +-----------+ Pull HTTP Request <------- <++++++++ HTTP Streaming HTTP Streaming -------> -------> Figure 5: Pull model for HTTP Streaming 8. HTTP Streaming Optimization Problem statement 8.1. Streaming Content Encoding Streaming begins with preparing the contents for delivery over the Internet. The process of encoding contents for streaming over the Internet is extremely complicated and demands extensive CPU power Wu Expires January 5, 2011 [Page 10] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 which can be very expensive in terms of equipment, resources and codec. Also Streaming service tends to over-utilize the CPU and bandwidth resource to provide better services to end users, which may be not desirable and effective way to improve the quality of streaming media delivery, e.g., when CPU resources are exhausted or insufficient, the encoding algorithm must sacrifice/downgrade quality to enable the process to keep pace with live contents rendering for viewing. When the encoding process is not fully functioned and flexible, content owner or encoder is forced to limit quality or viewing experience in order to support live streams. Apart from the consequences of CPU and bandwidth resource over- utilization, which are discussed in previous sub-sections, there are two additional effects that are undesirable: O For the non-scalable encoding, when MBR(i.e., Multiple Bit Rate) encoding is supported, the encoder usually generates multiple streams with different bit rates for the same media content, and encapsulates all these streams together, which needs additional processing capability and a possibly large storage and in worse case, may cause streaming session to suffer various quality downgrading, e.g., switching from high bit rate stream to low bit rate stream, rebufferring when the functionality of MBR is poorly utilized. O For the scalable encoding, it provides a scalable representation with layered bit streams decoding at different bit rate so that rate-control can be performed to mitigate network congestion. However, streaming application that employs layered coding is sensitive to transmission losses, especially the losses of base layer packets. Because the base layer represent the most critical part of the scalable representation. HTTP streaming optimization mechanism allows delivery of chunked contents. Rate control can be applied by the encoder on each chunked contents to adapt to bandwidth fluctuation and reduce the transmission loss. The rate control also provides Variable bit rate encoding which greatly improves the quality of the streaming by applying a higher number of available bits to scenes with high motion and fewer bits to scenes with little motion or low complexity. In contrast to MBR encoding, Layered video has the advantage of bandwidth efficiency and at the same time meets the real-time streaming requirement of clients with wide range of variation in processing power, display capability and network conditions. Also Wu Expires January 5, 2011 [Page 11] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 it does not need too much storage more than MBR encoding. Therefore it is desirable to use layered encoding in HTTP streaming to meet bandwidth-diverse customer requirement and minimize CPU power consumption. 8.2. Streaming Content Transmission HTTP is not streaming protocol but can be used to distribute small chunked contents in order, i.e., transmit the streaming contents relying on time-based operation. Since HTTP streaming is operated over TCP, it is much more likely to cause major packet drop-outs and greater delay due to TCP with the characteristic which keeps TCP trying to resend the lost packet before sending anything further. Thus HTTP streaming protocols suffer from the inefficient communication established by TCP's design and they are not well suited for delivering nearly the same amount of streams as UDP transmission or RTSP transmission. When network congestion happens, the transport may be degraded due to poor communication between client and server or slow response of the server for the transmission rate changes. Another major issue that plagues HTTP streaming is use of a single TCP connection. Using only a single TCP connection leaves the process susceptible to single failures. A single hung TCP connection causes the entire stream to freeze or severely reduces connection efficiency. This issue can be tackled by establishing multiple TCP connections between the client and the server which may need additional overhead for processing. By doing this, reliability and efficiency can be raised to near maximum, and latency is virtually eliminated. 8.3. Streaming Playback Control and navigation Playback control allows user interact with streaming contents to control presentation operation (e.g., fast forward, rewind, scrub, time-shift, or play in slow motion). RTSP streaming provides such capability to control and navigate the streaming session when the client receives the streaming contents. Unlike RTSP streaming, current HTTP streaming technologies do not provide such capability for playback control that users are accustomed to with DVD or television viewing, which significantly impacts the viewing experience. This also has the following effects that are not desirable: O When the user requests media fragments that correspond to the content's new time index and the media fragments from that point Wu Expires January 5, 2011 [Page 12] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 forward, the client can not have the possibility to change the time position for playback and select another stream for rendering with acceptable quality. O The user can not seek through media content whilst viewing the content with acceptable quality. O When the user requests to watch the relevant fragments rather than having to watch the full videos and manually scroll for the relevant fragments, the client can not have the possibility of jumping to another point within the media clip or between the media fragments with acceptable quality (i.e., random access). O When the media content the user requests to watch is live stream and needs to be interrupted in the middle, e.g., when the user takes a phone call, the client can not have the possibility to pause or resume the streaming session with acceptable quality after it has been invoked. O When the user begins to see the content at the new time point, if the media fragments retrieved when changing position require the same quality as the media fragments currently being played, it will result in poor user experience with longer startups latency. O When there are different formats corresponding to the terminal capabilities and user preferences available for contents, the client has no capability to select one format for which the content will be streamed. O When the user doesn't have time to watch all the streaming contents and want to skip trivial part and jump to the key part, the client does not provide the capability for selective preview or navigation control. O When the server wants to replace the currently transmitted video stream with a lower bit-rate version of the same video stream, the server has no capability to notify this to the client. 8.4. Streaming Monitoring and Feedback The usage of streaming media is rapidly increasing on the web. To provide a high-quality service for the user, monitoring and analyzing the system's overall performance is extremely important, since offering the performance monitoring capability can help diagnose the potential network impairment, facilitate in root cause analysis and verify compliance of service level agreements (SLAs) between Internet Service Providers (ISPs) and content provider. Wu Expires January 5, 2011 [Page 13] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 In the current HTTP streaming technology, it fails to give the server feedback about the experience the user actually had while watching a particular video. This is because the server controls all processes and it is impossible to track everything from the server side. Consequently, the server may be paying to stream content that is rarely or never watched. Alternatively, the server may have a video that continually fails to start or content that rebuffers continually. But the Content owner or encoder receives none of this information because there is no way to track it. Therefore it is desirable to allow the server view detailed statistics using the system's extensive network, quality, and usage monitoring capabilities. This detailed statistics can be in the form of real-time quality of service metrics data. 8.5. Streaming Content Protection In order to protect the content against theft or unauthorized use, the possible desirable features include: O Authorize users to view a stream once or an unlimited number of times. O Permit unlimited viewings but restrict viewing to a particular machine, a region of the world, or within a limit period of time. O Permit viewing but not copying or allow only one copy with a timestamp that prevents viewing after a certain time. O Charge per view or per unit of time, per episode, or view. 8.6. Streaming Timing Control and Synchronization 8.6.1. Timing control in the Push model In the push mode, the client just passively accepts what the server pushes out and always knows how the live stream is progressing. However if the client's clock is running slower than the encoder's clock, buffer overflow will happen, i.e., the client is not consuming samples as fast as the encoder is producing them. As samples get pushed to the client, more and more get buffered, and the buffer size keeps growing over time. This can cause the client to slow down packet processing and eventually run out of memory. On the other hand, if a client's clock is running faster than the encoder's clock, the client has to either keep re-buffering or tune Wu Expires January 5, 2011 [Page 14] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 down its clock. To detect this case, the client needs to distinguish this condition from others that could also cause buffer underflow, e.g. network congestion. This determination is often difficult to implement in a valid and authoritative manner. The client would need to run statistics over an extended period of time to detect a pattern that's most likely caused by clock drift rather than something else. Even with that, false detection can still happen. 8.6.2. Timing control in the Pull model In the pull model, the client is the one who initiates all the fragment requests and it needs to know the right timing information for each fragment in order to do the right scheduling [Smooth Streaming]. Given that the server is stateless in the pull model and the client could communicate with any server for the same streaming session, it has become more challenging. The solution is to always rely on the encoder's clock for computing timing information for each fragment and design a timing mechanism that's stateless and cacheable. With the pull model for HTTP Streaming, The client is driving all the requests and it will only request the fragments that it needs and can handle. In other words, the client's buffer is always synchronized to the client's clock and never gets out of control. The only side effect of this type of clock drift would be that the client could slowly fall behind, especially when transitioning from a "live" client to a DVR client (playing something stored in the past). 8.7. Streaming Session State Control In the push mode, the client state is managed both by the client and the server[Smooth Streaming]. The server keeps a record of each client for things such as playback state, streaming position, selected bit rate (if multiple bit rates are supported), etc. While this gives the streaming server more control, it also adds overhead to the server. What is more important is that each client has to maintain the server affinity throughout the streaming session, limiting scalability and creating a single point of failure. If somehow a client request is rerouted by a load balancer to another server in the middle of a streaming session, there is a high possibility that the request will fail. This limitation creates big challenges in server scalability and management for CDNs (i.e., Content Delivery Network) and server farms. Wu Expires January 5, 2011 [Page 15] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 In the pull mode, the client is solely responsible for maintaining its own state [Smooth Streaming]. In turn, the server is now stateless. Any client request (fragment or manifest) can be satisfied by any server that is configured for the same live content. The network topology can freely reroute the client requests to any server that is best for the client, which has advantage of load balancing. From the server's perspective, all client requests are equal. It doesn't matter whether they are from the same client or multiple clients, whether they are in live mode or DVR mode, which bit rate they're trying to play, whether they're trying to do bit rate switching, etc. They're all just fragment requests to the server, and the server's job is to manage and deliver the fragments in the most efficient way. Unlike some other implementations, the HTTP Streaming server's job is once again to keep all the content readily available to empower the client's decisions, and to make sure it presents the client with a semantically consistent picture. This has two benefits: (1) the feedback loop is much smaller as the client makes all the decisions, resulting in a much faster response (e.g. bit rate switching), and (2) it makes the server very lean and fast. Note that the division of the responsibilities between the server and the client has changed in the pull model. The server is focusing on delivering and managing fragments with the best possible performance and scalability, while the client is all about ensuring the smooth streaming/playback experience, which is a much better solution for large-scale online video. 9. Analysis of different use cases 9.1. Content Publishing HTTP Streaming can be used in the CDN to optimize content delivery. Content Publisher may utilize HTTP Streaming to publish the popular contents on the sever to the Web Cache, which, in turn, reduce bandwidth requirements and server load, improve the client response times for content stored in the cache. Also when the web cache fails to provide the contents that have greatest demand to the requester (e.g., Client), the web cache can use HTTP Streaming protocol to retrieve the contents from the server and cache them waiting for the next request from the requester. 9.2. "Multi-Screen" Video Delivery "Multi-Screen" Shared Service means content for delivery using CDN through multiple delivery channels to multiple device types (e.g., mobile devices, set-top-boxes, gaming consoles). Multi-Screen Video Delivery may utilize HTTP Streaming with Scalable Encoding to meets Wu Expires January 5, 2011 [Page 16] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 the real-time streaming requirement of clients with wide range of variation in processing power, display capability and network conditions. 9.3. Time Shifted Playback Time Shifted Playback can be integrated with HTTP Streaming to provide the same viewing experiences as DVD or television viewing that users are early accustomed to. 10. Security Consideration TBD. 11. References 11.1. Normative References [Microsoft] http://msdn.microsoft.com/en- us/library/cc251059(PROT.10).aspx [Streaming Protocol] Transparent end-to-end Packet-switched Streaming Service (PSS);Protocols and codecs (Release 9) [Media Fragments] http://www.w3.org/2008/WebVideo/Fragments/WD-media- fragments-spec/ [OIPF] OIPF Release 1 Specification Profiles [Smooth Streaming] http://blogs.iis.net/samzhang/archive/2009/03/27/live -smooth-streaming-design-thoughts.aspx [RFC2326] Schulzrinne,H.,Rao, A.,R.Lanphier," Real Time Streaming Protocol (RTSP)",RFC2326,April,1998 [RFC1945] Berners-Lee,T.,Fielding,R.,H.Frystyk," Hypertext Transfer Protocol -- HTTP/1.0", RFC1945, May,1996 [MMS] MMS streaming protocol, http://sdp.ppona.com. [I.D-pantos-http-live-streaming] Wu Expires January 5, 2011 [Page 17] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 Pantos,R.,W.,May "HTTP Live Streaming", draft-pantos-http- live-streaming-04 (work in progress), June,2010 [TS 26.234]3GPP TS 26.234, "Transparent end-to-end Packet-switched Streaming Service (PSS);Protocols and codecs (Release 9)" [RDT] Real data transport (RDT), http://protocol.helixcommunity.org/. [Fast Streaming] Fast Streaming with Windows Media 9 Series, http://www.microsoft.com/. 11.2. Informative References [PMOLFRAME] Clark, A., "Framework for Performance Metric Development", ID draft-ietf-pmol-metrics-framework-02, March 2009. [J.1080] Recommendation ITU-T G.1080 "Quality of experience requirements for IPTV services" Wu Expires January 5, 2011 [Page 18] Internet-Draft HTTP Streaming Optimization Problem Statement July 2010 Authors' Addresses Qin Wu Huawei Technologies Co.,Ltd. Site B, Floor 12F,Huihong Mansion, No.91,Baixia Rd. Phone: +86-25-84565892 Email: sunseawq@huawei.com Wu Expires January 5, 2011 [Page 19]