One document matched: draft-wu-http-streaming-optimization-ps-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 19:34:13 |