<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-wu-http-streaming-optimization-ps-03"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="HTTP Streaming Problem Statement">Problem Statement for
    HTTP Streaming</title>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>sunseawq@huawei.com</email>
      </address>
    </author>

    <author fullname="Rachel Huang" initials="R." surname="Huang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>Rachel@huawei.com</email>
      </address>
    </author>

    <date month="October" year="2010" />

    <workgroup>Network Working Group</workgroup>

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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. </t>

      <t>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:<vspace
      blankLines="1" /><list style="symbols">
          <t>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.<vspace
          blankLines="1" /></t>

          <t>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.<vspace
          blankLines="1" /></t>
        </list></t>

      <t>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.</t>

      <t>With media segmentation support, existing HTTP streaming technology
      (e.g., progressive download HTTP streaming) is characterized as:<vspace
      blankLines="1" /><list style="symbols">
          <t>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. <vspace blankLines="1" /></t>

          <t>Relying on existing web infrastructure, i.e., no special server
          and intermediaries are required other than a standard HTTP Server
          and HTTP caches/proxies.<vspace blankLines="1" /></t>
        </list></t>

      <t>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:<vspace
      blankLines="1" /><list style="symbols">
          <t>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.<vspace blankLines="1" /></t>

          <t>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.<vspace blankLines="1" /></t>

          <t>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. <vspace blankLines="1" /></t>

          <t>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.<vspace blankLines="1" /></t>

          <t>Lacking multicast support.<vspace blankLines="1" /></t>
        </list></t>

      <t>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 service provider and users.</t>

      <t>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.</t>
    </section>

    <section title="Terminology">
      <t>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 <xref
      target="RFC2119"></xref>.</t>

      <t><list style="hanging">
          <t hangText="Push Model:">The model that allows the server keep
          pushing data packets to the client.<vspace blankLines="1" /></t>

          <t hangText="Pull Model:">The model that allows the client keep
          pulling data packets from the server.<vspace blankLines="1" /></t>

          <t hangText="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.<vspace blankLines="1" /></t>

          <t hangText="On-Demand Streaming:">To provide "anytime" access to
          media content, client is allowed to select and playback on
          demand.<vspace blankLines="1" /></t>

          <t hangText="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.<vspace blankLines="1" /></t>

          <t hangText="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.<vspace blankLines="1" /></t>
        </list></t>
    </section>

    <section anchor="sec.3" title="Architecture of HTTP Streaming System">
      <t><xref target="fig1"></xref> shows reference Architecture for HTTP
      Streaming in general case. The Architecture should comprise the
      following components:<vspace blankLines="1" /></t>

      <figure align="center" anchor="fig1"
              title="Reference Architecture for HTTP Streaming">
        <artwork>
+--Streaming--+        +-Distribution+       +-  Client -+
|  Component  |        |  Component  |       | Component |
|  +-------+  |        | +--------+  |       |  +------+ |
|  | Media |  |        | |  HTTP  |  |       |  | HTTP | |
|  |Encoder|  |        | | Proxy/ |  |       |  |Client| |
|  +-------+  |        | | Server |  |       |  +------+ |
| +---------+ |-------&gt;| +--------+  |------&gt;|           |
| |Streaming| |        | +-------+   |       |           |
| |Segmenter| |&lt;-------| |Network|   |&lt;------|+---------+|
| +---------+ |        | | Cache |   |       ||Streaming||
|  +------+   |        | +-------+   |       ||  Client ||
|  | HTTP |   |        | +---------+ |       |+---------+|
|  |Server|   |        | |Streaming| |       |           |
|  +------+   |        | | Engine  | |       +-----------+
+-------------+        | +---------+ |
                       +-------------+        
</artwork>
      </figure>

      <t><list style="symbols">
          <t>Streaming Component<vspace blankLines="1" /></t>

          <t>Distribution Component<vspace blankLines="1" /></t>

          <t>Client Component<vspace blankLines="1" /></t>
        </list></t>

      <section title="Functions of Streaming Components">
        <figure align="center" anchor="fig2"
                title="Functions of Streaming Component">
          <artwork>
+--------------------+----------------------------------------------+
| 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                          |
+--------------------+----------------------------------------------+
</artwork>
        </figure>
      </section>

      <section title="Functions of Distribution Components">
        <figure align="center" anchor="fig3"
                title="Functions of Distribution Component">
          <artwork>
+--------------------+----------------------------------------------+
| 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     |
+--------------------+----------------------------------------------+
</artwork>
        </figure>
      </section>

      <section title="Functions of Client Components">
        <figure anchor="fig4" title="Functions of Client Components">
          <artwork>
+--------------------+----------------------------------------------+
| Function           |                       Role                   |
+--------------------+----------------------------------------------+
| Streaming          |                                              |
|   Client           | Handle Streaming Playout and Buffer          |
|                    |                                              |
| -                  | -                                            |
|    HTTP            | Initialize HTTP Connection                   |
|   Client           |                                              |
+--------------------+----------------------------------------------+
</artwork>
        </figure>
      </section>
    </section>

    <section title="Existing Work and Model">
      <t>Based on the architecture described in <xref target="sec.3"></xref>,
      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.</t>

      <section title="Media Fragments URI">
        <t>W3C Media Fragments Working Group extends URI defined in <xref
        target="RFC3986"></xref>and specifies some new semantics of URI
        fragments and URI queries <xref target="MediaFragments"></xref> which
        is used to identify media fragments. The 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.</t>
      </section>

      <section title="Media Presentation Description">
        <t> <xref target="I.D-pantos-http-live-streaming"></xref>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 <xref
        target="TS26.234"></xref>, which contains metadata required by the
        client(i.e., Smartphone) to construct appropriate URIs <xref
        target="RFC3986"></xref>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 <xref
        target="GapAnalysis"></xref></t>
      </section>

      <section title="Playback Control on media fragments">
        <t>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 &lt;object&gt; element and put it into
        specialized &lt;video&gt; handlers. With such playback control
        support, implementers can choose to create their own controls with
        plain old HTML, CSS, and JavaScript. However this playback control can
        not be used to control streaming contents which are not downloaded to
        the browser client. Another example of playback control is trick mode
        support specified in 3GPP HTTP Adaptive Streaming <xref
        target="TS26.234"></xref>, where the client can implement seeking by
        locating the corresponding chunk by using the information acquired in
        MPD. More survey on playback control can also be found in
        [GapAnalysis]</t>
      </section>

      <section title="Server Push">
        <t>W3C Server Sent Push specification defines an API for opening an
        HTTP connection for receiving push notifications from a server.
        However there is no server-push protocol to be defined in IETF, which
        can be used to work with Server Sent Push API developed by W3C. IETF
        Hybi working group specifies websocket protocol, as one complementary
        work, W3C specifies websocket API. This websocket technology provides
        two-way communication with servers that does not rely on opening
        multiple HTTP connections. However it still lacks capability to push
        real time streaming data from the server-side to the client.</t>
      </section>

      <section title="Existing HTTP Streaming Model(Client Pull Model)">
        <t>In the HTTP Streaming Pull model, the Distribution component does
        not take a stab into HTTP Streaming traffic. The Streaming Content
        flows directly from the server to the Client. Adaptive HTTP Streaming
        specified in 3GPP is one typical example of pull model. In the
        adaptive HTTP Streaming, the video streaming application is decoupled
        from existing web infrastructure However, how the streaming contents
        is distributed from dedicated streaming server to HTTP Server is
        unspecified. This put Streaming live video feeds problematic. Internet
        streams created from live video feeds are usually fraught with
        glitches and interruptions. Once again, image quality, size and
        features are sacrificed because of limited encoding CPU resources and
        the absolute need to “keep up” with the live feed.</t>

        <figure align="center" anchor="fig5"
                title="Pull model for HTTP Streaming">
          <artwork>
  Streaming                                       +-   HTTP  -+
 + Server  --+                                   Streaming Client 
 |           |                                    |  +------+ |
 | +-------+ |                     HTTP           |  | HTTP | |
 | | Media | |                     Proxy          |  |Client| |
 | |Encoder| |       +------+      +------+       |  +------+ |
 | +-------+ |       | HTTP |------+------+------&gt;|           |
 |+---------+|       |Server|&lt;-----+------+-------|           |
 ||Streaming||       +------+      +------+       |+---------+|
 ||Segmenter||                                    ||Streaming||
 |+---------+|                                    ||  Client ||
 |           |                                    |+---------+|
 |           |                                    |           |
 +-----------+                                    +-----------+    
</artwork>
        </figure>
      </section>
    </section>

    <section title="Analysis of different use cases">
      <section title="Live Streaming Media broadcast">
        <t>Today, live video streaming technologies are widely used in
        broadcasting news, connecting friends and relatives in online chat
        rooms, conducting businesses online face to face, selling products and
        services, teaching online courses, monitoring properties, showing
        movies online, and so on. Current HTTP streaming (both live streaming
        and VoD) is based on the pull model in which the client pulls a
        sequence of chunks one after another from the server, based on the
        manifest file produced by the server describing currently available
        chunks. The pull model gives a better control of media delivery,
        better handling of chunk scheduling, as well as buffer management on
        the client's side. In the case of live streaming, the server will need
        to update the manifest file frequently once a new chunk of live media
        becomes available. This may cause a major concern in time-sensitive
        scenario. There will be two 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.</t>

        <t>HTTP server push model, on the other hand, enables the server to
        actively and continuously push chunks to the client once a new chunk
        is available on the server, without the round trips between the client
        and the server for manifest file update. In this sense, push model
        could be more efficient and a better candidate for time-sensitive
        scenario.</t>
      </section>

      <section title="“Multi-Screen” Service Delivery">
        <t>With the existing deployment today, the services like Network DVR
        and TV/Video anywhere are generally limited as to the types of device
        that they support, or the level of integration and interactivity
        between screens. “Multi-Screen” Service provides a common user
        experience across PCs, TVs, Smartphones, Tablets that enable consumers
        to access the same media content and quality of experience (QoE) on
        any device, anytime and anywhere. Such multi-Screen Experience is
        lacking for end user in the services like Network DVR and TV/Video
        anywhere. Since all the clients have browser support, it is obviously
        one best choice to choose HTTP Streaming to deliver Multi-Screen
        Service. However utilizing HTTP Streaming to deliver Multi-Screen
        Service and meet the real time streaming requirements face several
        great challenges, which include:<vspace blankLines="1" /><list
            style="hanging">
            <t hangText="Startup delay:"><vspace blankLines="1" /><list
                style="symbols">
                <t>Compared to the dedicated IPTV system, the HTTP streaming
                based on the best-effort Internet may suffer more from network
                transition. Although the client buffer can mitigate the
                overall effect of network transition, there is lack of
                guarantee on startup delay, which is an important QoE metric.
                For example, when a user switches live channel, the current
                group of pictures (GoP) and initialization information for
                decoders (a.k.a. Reference Information (RI)) of the media
                content need to be acquired by the client ASAP to start
                playback. Rapid Acquisition of Multicast Session (RAMS) [RAMS]
                defined in IETF AVT WG aims to address the similar problem in
                the case of MPEG2-TS over RTP transmission by storing the
                important RTP packets for quick startup in intermediary node
                and feeding the packets to the client with high priority.
                Unfortunately, there is no mechanism so far to improve the
                transmission of the important HTTP packets, hence may
                introduce a long delay to start the playback in the scenario
                of HTTP streaming.<vspace blankLines="1" /></t>

                <t>With the intermediary nodes, it is possible that the
                important HTTP packets, e.g. those including current GoP and
                RI of the media content can be stored before the client
                switches live channel or start VoD. Then it could be possible
                to reduce the startup delay on the client by transmitting
                these packets to the client from the intermediaries, which are
                closer to the client than the normal HTTP server. Furthermore,
                the intermediaries could transmit these packets with higher
                priority than other HTTP packets, or faster than playback
                bit-rate, to achieve further QoE enhancement on the client
                side.<vspace blankLines="1" /></t>
              </list></t>

            <t hangText="QoE feedback:"><vspace blankLines="1" /><list>
                <t>In IPTV system, RTCP is responsible for sending the
                feedback about the media transmission quality to the media
                server. In the case of HTTP streaming, due to reliable data
                transmission provided by TCP, QoE metrics related to data
                transport such as packet loss are not relevant. However, some
                QoE metrics at session level, such as startup delay are still
                important to the HTTP streaming system for monitoring or
                diagnostic purpose. Unfortunately, there is no such quality
                monitoring mechanisms (e.g. like RTCP report) in current HTTP
                streaming system. 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. Furthermore QoE feedback
                mechanisms will facilitate in root cause analysis and verify
                compliance of service level agreements (SLAs) between service
                providers and users.<vspace blankLines="1" /></t>
              </list></t>
          </list></t>
      </section>

      <section title="Content Publishing between Servers">
        <t>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 Streaming sever to the Web Server or Proxy, 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 web server and cache them
        on the web proxy waiting for the next request from the requester.</t>
      </section>
    </section>

    <section title="Aspects of Problem">
      <t>The Real time streaming service (e.g., RTSP) is superior in handling
      thousands of concurrent streams simultaneously, e.g., flexible responses
      to network congestion, efficient bandwidth utilization, and high quality
      performance. 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. </t>

      <section title="Inefficient Streaming Content Delivery">
        <t>HTTP is not streaming protocol but can be used to distribute small
        chunked contents in order, e.g., transmit any media contents relying
        on time-based operation. However Client polling for each new data in
        chunks may not be efficient way to deliver high-quality streaming
        video content across the Internet for the following reasons:<vspace
        blankLines="1" /><list style="symbols">
            <t>Clients today send a significant amount of redundant data in
            the form of HTTP headers. Because a single web page may require 50
            or 100 sub-requests, this data is significant. It is desirable to
            compress the headers which may save a significant amount of
            latency and bandwidth compared to HTTP.<vspace
            blankLines="1" /></t>

            <t>Clients can not request certain resources to be delivered
            first. This may cause the problem of congesting the network
            channel with non-critical resources when a high-priority request
            is pending.<vspace blankLines="1" /></t>

            <t>HTTP relies solely on multiple connections for concurrency.
            This causes several problems, including additional round trips for
            connection setup, slow-start delays, and a constant rationing by
            the client where it tries to avoid opening too many connections to
            a single server.<vspace blankLines="1" /></t>

            <t>Since HTTP 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.<vspace
            blankLines="1" /></t>

            <t>Client polling may keep waiting for the arrival of data in
            response to the previous request before sending the next new
            request.<vspace blankLines="1" /></t>

            <t>In the case of live streaming, the server will need to update
            the manifest file frequently once a new chunk of live media
            becomes available. This may cause a major concern in
            time-sensitive scenario. 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.<vspace blankLines="1" /></t>
          </list></t>

        <t>Therefore it is desirable to offer better transport for streaming
        contents delivery.</t>
      </section>

      <section title="No QoE Guaranteed Support">
        <t>Due to the lack of QoE guarantee on the packet switching based
        Internet, the internet streaming can only provide best effort quality
        to consumers.</t>

        <t>This may have the following effects that are not desirable:<vspace
        blankLines="1" /><list style="symbols">
            <t>The quality of Internet media streaming may significantly
            degrade due to rising usage and concurrent streaming delivery. The
            Internet traffic generated by HTTP streaming may exhibit
            burstiness extremely or other dynamics changes.<vspace
            blankLines="1" /></t>

            <t>The filling of the client play-out buffer, which is used to
            smooth jitter caused by network bandwidth fluctuation, may further
            increase user’s waiting time.<vspace blankLines="1" /></t>

            <t>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, in worse case, the server may not have enough
            bandwidth to support all of the client connections. When CPU
            resources are exhausted or insufficient, the server must
            sacrifice/downgrade quality to enable the process to keep pace
            with live contents rendering for viewing. Therefore the content
            owner is forced to limit quality or viewing experience in order to
            support live streams.<vspace blankLines="1" /></t>

            <t>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.<vspace
            blankLines="1" /></t>
          </list></t>

        <t>A study conducted by StreamGuard.net examined more than 2,400
        different Internet video streams. They concluded that:<vspace
        blankLines="1" /><list style="symbols">
            <t>51% of stream viewers were frustrated with the
            experience.<vspace blankLines="1" /></t>

            <t>17% of streams have an immediate fatal error.<vspace
            blankLines="1" /></t>

            <t>25% take between 5 and 10 seconds to start playing, and stop to
            rebuffer before the video is finished.<vspace
            blankLines="1" /></t>
          </list></t>

        <t>With current technologies, dial-up users do not typically attempt
        video streaming and broadband users often give up after prolonged
        waits or unresponsiveness due to regular rebuffering.</t>
      </section>

      <section title="No QoS Control and Feedback Support">
        <t>The usage of streaming media is rapidly increasing on the web. To
        provide a high-quality service for the user, QoS control such as
        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.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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.</t>
      </section>

      <section title="No Streaming Content Distribution and Discovery Support">
        <t>Unlike standard web pages and graphics and P2P Streaming data,
        streaming video files may not be cacheable by web cache servers on the
        network or by the browser on your local hard drive. Therefore how to
        distribute the streaming video files to the distributed component in
        the Content Delivery Network and how the distribution server serves
        the Client with these streaming video files are still problematic
        issues.</t>
      </section>

      <section title="Lacking Streaming media Synchronization support">
        <t>In the push model, 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 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. </t>

        <t>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.</t>

        <t>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. Currently most of
        existing streaming schemes are based on pull model. However the 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). </t>
      </section>

      <section title="No Multicast Support">
        <t>HTTP is sent over TCP and only supports unicast which may increase
        processing overhead by 30% in contrast with using multicast
        transmission.</t>
      </section>

      <section title="Inadequate Streaming Playback Control">
        <t>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.</t>

        <t>This also has the following effects that are not desirable:<vspace
        blankLines="1" /><list style="symbols">
            <t>When the user requests media fragments that correspond to the
            content’s new time index and the media fragments from that point
            forward, the client can not have the possibility to change the
            time position for playback and select another stream for rendering
            with acceptable quality. <vspace blankLines="1" /></t>

            <t>The user can not seek through media content whilst viewing the
            content with acceptable quality.<vspace blankLines="1" /></t>

            <t>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).<vspace blankLines="1" /></t>

            <t>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. <vspace blankLines="1" /></t>

            <t>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.<vspace blankLines="1" /></t>

            <t>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.<vspace blankLines="1" /></t>

            <t>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.<vspace blankLines="1" /></t>

            <t>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.<vspace blankLines="1" /></t>
          </list></t>
      </section>
    </section>

    <section title="Scope of the problem">
      <t>Goal: Develop interoperable solutions that offer more efficient
      transport for real time streaming media and allows interoperability with
      other existing streaming techniques.</t>

      <t>Possible Directions forward:<vspace blankLines="1" /><list
          style="symbols">
          <t>Specify how an application running over HTTP should operate in
          order to be able to support HTTP streaming and avoid certain
          challenges/issues<vspace blankLines="1" /></t>

          <t>Extend websocket protocol to support HTTP Streaming and avoid
          certain challenges/issues<vspace blankLines="1" /></t>

          <t>Build a different protocol to HTTP like RTMP for streaming
          data<vspace blankLines="1" /></t>

          <t>Specify a different transport layer for HTTP to avoid the
          problems<vspace blankLines="1" /></t>

          <t>Other suggestions from working group via mailing list or ad-hoc
          meeting<vspace blankLines="1" /></t>
        </list></t>

      <t>Possible Models to be built:</t>

      <section title="Enhanced HTTP Streaming Pull model">
        <t>Unlike the basic pull model defined in section 5.1, the interface
        between the Streaming Server and the Distribution Server is defined.
        HTTP Streaming schemes is used for data transport between two servers.
        Also the Distribution Component is introduced with Streaming support
        to provide a "hint" to the server/cache as to which chunk the client
        is likely to request next then the distribution component could elect
        to retrieve that chunk ahead of it actually being requested to keep
        the response latency (or some other factor) more consistent and avoid
        additional bit rate switches. </t>

        <figure align="center" anchor="fig6"
                title="Enhanced Pull model with involvement of Distribution Component">
          <artwork>
  Streaming             +-Distribution+
 + Server  --+          |  Component  |           HTTP Streaming
 |           |          | +--------+  |           +-- Client--+
 | +-------+ |  HTTP    | |  HTTP  |  |   HTTP    |           |
 | | Media | |Streaming | | Proxy/ |  | Streaming |  +------+ |
 | |Encoder| | Traffic  | | Server |  |  Traffic  |  | HTTP | |
 | +-------+ |---------&gt;| +--------+  |----------&gt;|  |Client| |
 |+---------+|          | +-------+   |           |  +------+ |
 ||Streaming||          | |Network|   |           |           |
 ||Segmenter||&lt;-------- | | Cache |   |&lt;----------|           |
 |+---------+|  Pull    | +-------+   HTTP Request|+---------+|
 | +------+  |          | +---------+ |           ||Streaming||
 | | HTTP |  |          | |Streaming| |           ||  Client ||
 | |Server|  |          | | Engine  | |           |+---------+|
 | +------+  |          | +---------+ |           |           |
 +-----------+          +-------------+           +-----------+ 
</artwork>
        </figure>
      </section>

      <section title="HTTP Streaming Push model">
        <t>In the push model, there may have one or more than one Distribution
        Servers placed between HTTP Streaming Server and HTTP Streaming
        Client. </t>

        <t>When the Distribution Server does not get involved in HTTP
        Streaming, Streaming Content flows directly from the server to the
        Client. The server keeps pushing the latest data packets to the client
        and the client just passively receives everything. The distribution
        server is just responsible for forwarding stream as all the other HTTP
        proxies do. </t>

        <t>When the Distribution Server gets involved in HTTP Streaming, The
        HTTP Streaming Server keeps pushing the latest data packets to the
        client, in the meanwhile, the HTTP Streaming server may also push the
        data packets to the distribution server for caching when there is
        enough interest from clients on the same streams. When the new client
        requests the same data packets as the previous client 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.</t>

        <figure align="center" anchor="fig7"
                title="Push model for HTTP Streaming">
          <artwork>
  Streaming           +-Distribution+
 + Server  --+        |  Component  |         HTTP Streaming
 |           |        | +--------+  |         +-- Client--+
 | +-------+ |        | |  HTTP  |  |         |           |
 | | Media | |        | | Proxy/ |  |         |  +------+ |
 | |Encoder| |        | | Server |  |         |  | HTTP | |
 | +-------+ |        | +--------+  |         |  |Client| |
 |+---------+|        | +-------+   |         |  +------+ |
 ||Streaming||        | |Network|   |         |           |
 ||Segmenter||        | | Cache |   |         |           |
 |+---------+|        | +-------+   |         |+---------+|
 | +------+  |        | +---------+ |         ||Streaming||
 | | HTTP |  |        | |Streaming| |         ||  Client ||
 | |Server|  |        | | Engine  | |         |+---------+|
 | +------+  |        | +---------+ |         |           |
 +-----------+        +-------------+         +-----------+
                            Push
               ------------------------------&gt;
                Push   HTTP Streaming
              -------&gt;               HTTP Request
                                     &lt;+++++++
                                       Push
                                     --------&gt;             
</artwork>
        </figure>
      </section>
    </section>

    <section title="Security Considerations">
      <t>In order to protect the content against theft or unauthorized use,
      the possible desirable features include:<vspace blankLines="1" /><list
          style="symbols">
          <t>Authorize users to view a stream once or an unlimited number of
          times.<vspace blankLines="1" /></t>

          <t>Permit unlimited viewings but restrict viewing to a particular
          machine, a region of the world, or within a limit period of
          time.<vspace blankLines="1" /></t>

          <t>Permit viewing but not copying or allow only one copy with a
          timestamp that prevents viewing after a certain time.<vspace
          blankLines="1" /></t>

          <t>Charge per view or per unit of time, per episode, or view.<vspace
          blankLines="1" /></t>
        </list></t>
    </section>

    <section title="Acknowledgement">
      <t>The authors would like to thank David A. Bryan, Ning Zong,Bill Ver
      Steeg, Ali Begen, Colin Perkins, Roni Even, Daniel Park, Henry
      Sinnreich, Wenbo Zhu, Lars Eggert, Spencer Dawkins, Ben Niven-Jenkins,
      Marshall Eubanks, Kathy McEwen for their suggestions and inputs on this
      document. Also Thanks Thomas Stockhammer,Luby, Michael, Mark Watson for
      their precious comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2326"?>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.1945"?>

      <?rfc include="reference.RFC.3986"?>

      <reference anchor="TS26.234">
        <front>
          <title>Transparent end-to-end Packet-switched Streaming Service
          (PSS);Protocols and codecs (Release 9)</title>

          <author>
            <organization>3GPP Standard</organization>
          </author>

          <date month="March" year="2010" />
        </front>

        <seriesInfo name="3GPP TS 26.234" value="" />
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="RAMS">
        <front>
          <title>Unicast-Based Rapid Acquisition of Multicast RTP
          Sessions</title>

          <author fullname="Bill VerSteeg " initials="B." surname="VerSteeg ">
            <organization>Cisco</organization>
          </author>

          <author fullname="Ali Begen " initials="A." surname="Begen ">
            <organization>Apple</organization>
          </author>

          <author fullname="Tom VanCaenegem" initials="T."
                  surname="VanCaenegem">
            <organization>ALU</organization>
          </author>

          <author fullname="Zeev Vax " initials="Z." surname="Vax">
            <organization>Microsoft</organization>
          </author>

          <date month="October" year="2010" />
        </front>

        <seriesInfo name="Internet-Draft"
                    value="draft-ietf-avt-rapid-acquisition-for-rtp-16" />
      </reference>

      <reference anchor="I.D-pantos-http-live-streaming">
        <front>
          <title>HTTP Live Streaming</title>

          <author fullname="R.Pantos" initials="R." surname="Pantos">
            <organization>Apple</organization>
          </author>

          <author fullname="W.May" initials="W." surname="May">
            <organization>Apple</organization>
          </author>

          <date month="June" year="2010" />
        </front>
      </reference>

      <reference anchor="GapAnalysis">
        <front>
          <title>Survey and Gap Analysis for HTTP Streaming Systems</title>

          <author fullname="Ning Zong" initials="N." surname="Zong">
            <organization>Huawei</organization>
          </author>

          <date month="October" year="2010" />
        </front>
      </reference>

      <reference anchor="J.1080">
        <front>
          <title>Quality of experience requirements for IPTV services</title>

          <author>
            <organization>ITU-T</organization>
          </author>

          <date month="" year="" />
        </front>

        <seriesInfo name="Recommendation ITU T G.1080" value="" />
      </reference>

      <reference anchor="I-D.ietf-pmol-metrics-framework-02">
        <front>
          <title>Framework for Performance Metric Development</title>

          <author fullname="Alan Clark " initials="A." surname="Clark">
            <organization>Telchemy Incorporated</organization>
          </author>

          <date />
        </front>
      </reference>

      <reference anchor="HTML5">
        <front>
          <title>HTML5</title>

          <author>
            <organization>W3C</organization>
          </author>

          <date month="" year="" />
        </front>

        <seriesInfo name="http://www.w3.org/TR/html5/video.html#media-elements"
                    value="" />
      </reference>

      <reference anchor="ServerSentEvent">
        <front>
          <title>Server Sent Event</title>

          <author>
            <organization>W3C</organization>
          </author>

          <date month="" year="" />
        </front>

        <seriesInfo name="http://www.w3.org/TR/eventsource/" value="" />
      </reference>

      <reference anchor="MediaFragments">
        <front>
          <title>Media Fragments</title>

          <author>
            <organization>W3C</organization>
          </author>

          <date month="" year="" />
        </front>

        <seriesInfo name="http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/"
                    value="" />
      </reference>

      <reference anchor="SmoothStreaming">
        <front>
          <title>Smooth Streaming</title>

          <author>
            <organization>Microsoft</organization>
          </author>

          <date />
        </front>

        <seriesInfo name="http://blogs.iis.net/samzhang/archive/2009/03/27/live-smooth-streaming-design-thoughts.aspx"
                    value="" />
      </reference>
    </references>
  </back>
</rfc>
