Network Working Group Q. Wu
Internet-Draft R. Huang
Intended status: Standards Track Huawei
Expires: April 28, 2011 October 25, 2010
Problem Statement for HTTP Streaming
draft-wu-http-streaming-optimization-ps-03
Abstract
HTTP Streaming allows breaking the live contents or stored contents
into several chunks/fragments and supplying them in order to the
client. However streaming long duration and high quality media over
the internet to satisfy the real time streaming requirements has
several Challenges when we require the client to access the same
media content with the common Quality experience at any device,
anytime, anywhere. This document explores problems inherent in HTTP
streaming. Several issues regarding network support for HTTP
Streaming have been raised, which include QoE improvement offering to
streaming video over Internet, efficient delivery, Playback control
and real time streaming media synchronization support.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Wu & Huang Expires April 28, 2011 [Page 1]
Internet-Draft HTTP Streaming Problem Statement October 2010
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Wu & Huang Expires April 28, 2011 [Page 2]
Internet-Draft HTTP Streaming Problem Statement October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architecture of HTTP Streaming System . . . . . . . . . . . . 6
3.1. Functions of Streaming Components . . . . . . . . . . . . 7
3.2. Functions of Distribution Components . . . . . . . . . . . 8
3.3. Functions of Client Components . . . . . . . . . . . . . . 8
4. Existing Work and Model . . . . . . . . . . . . . . . . . . . 8
4.1. Media Fragments URI . . . . . . . . . . . . . . . . . . . 8
4.2. Media Presentation Description . . . . . . . . . . . . . . 9
4.3. Playback Control on media fragments . . . . . . . . . . . 9
4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Existing HTTP Streaming Model(Client Pull Model) . . . . . 10
5. Analysis of different use cases . . . . . . . . . . . . . . . 10
5.1. Live Streaming Media broadcast . . . . . . . . . . . . . . 10
5.2. "Multi-Screen" Service Delivery . . . . . . . . . . . . . 11
5.3. Content Publishing between Servers . . . . . . . . . . . . 12
6. Aspects of Problem . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Inefficient Streaming Content Delivery . . . . . . . . . . 13
6.2. No QoE Guaranteed Support . . . . . . . . . . . . . . . . 14
6.3. No QoS Control and Feedback Support . . . . . . . . . . . 15
6.4. No Streaming Content Distribution and Discovery Support . 16
6.5. Lacking Streaming media Synchronization support . . . . . 16
6.6. No Multicast Support . . . . . . . . . . . . . . . . . . . 17
6.7. Inadequate Streaming Playback Control . . . . . . . . . . 17
7. Scope of the problem . . . . . . . . . . . . . . . . . . . . . 18
7.1. Enhanced HTTP Streaming Pull model . . . . . . . . . . . . 19
7.2. HTTP Streaming Push model . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Wu & Huang Expires April 28, 2011 [Page 3]
Internet-Draft HTTP Streaming Problem Statement October 2010
1. Introduction
Streaming service is described as transmission of data over network
as a steady continuous stream, allowing playback to proceed while
subsequent data is being received, which may utilize multiple
transport protocols for data delivery. HTTP streaming refers to the
streaming service wherein the HTTP protocol is used for basic
transport of media data. One example of HTTP streaming is
progressive download streaming which allows the user to access
content using existing infrastructure before the data transfer is
complete.
In recent years, HTTP streaming system has been widely used on the
Internet for the delivery of multimedia content. There are several
reasons for this industry trend, for example:
o Existing Media Streaming protocols often have difficulty getting
around firewalls because they are commonly based on UDP with
unusual port numbers. HTTP streaming has no such problems because
firewalls know to pass HTTP packets through well-known port 80.
o Due to the success of Web, both HTTP server and HTTP client are
quite common in industry, which means that building a HTTP based
media delivery system may have less cost compared to those using
dedicated media server/client and intermediaries.
In order to better support the streaming characteristics, such as
trick modes, adaptation to resolutions, some approaches have been
commonly adopted in current HTTP streaming systems. For example,
media segmentation method separates the whole media content to a
series of small chunks and supplies them to the client through a
sequence of HTTP responses. Segmentation allows the client to seek
to different piece of media content, change the bit-rate of the next-
to-fetch chunk, as well as enables reducing the overall transmission
delay in case that one TCP connection trying to resend the lost
packet before sending anything further.
With media segmentation support, existing HTTP streaming technology
(e.g., progressive download HTTP streaming) is characterized as:
o Client based pull schemes that is, the client firstly acquires a
manifest file containing the reference (e.g. URI) to each media
chunks from the streaming server, then requests the media chunks
by forming a sequence of HTTP request messages to the server.
This client based pull model more relies on client to handle
buffer and playback during download.
Wu & Huang Expires April 28, 2011 [Page 4]
Internet-Draft HTTP Streaming Problem Statement October 2010
o Relying on existing web infrastructure, i.e., no special server
and intermediaries are required other than a standard HTTP Server
and HTTP caches/proxies.
However streaming long duration and high quality media over the
internet to offer TV experience at any device and satisfy the real
time streaming requirements faces several unique Challenges when
there are no network capabilities available for HTTP Streaming:
o In client pull model, there will be additional round trips between
the client and the server for manifest file update before the
client can request each new chunk, which could risk the real-time
feature of live streaming.
o Lack of QoE guarantee on the packet switching based Internet and
hard to offer better experience than TV viewing. Compared to the
dedicated IPTV system, the HTTP streaming based on the best-effort
Internet may suffer more from network transition. For example,
when a user switches live channel or start VoD, there is no
guarantee on startup time.
o Lack of Feedback on Quality of data delivery. e.g., there is no
streaming quality control mechanisms like RTCP to report QoE
metrics that are important to the HTTP streaming system for
control or diagnostic purpose.
o Lack of QoS Control. For example, there is no QoS difference
between high speed Internet traffic and Streaming over Internet
traffic and hard for QoS surcharges on consumer broadband
subscription.
o Lacking multicast support.
With these above challenges, the typical user experience with the
existing HTTP streaming schemes may be limited by unacceptable
latency and waiting time, better effort quality, buffering delays or
interruption, etc, and inadequate playback control, especially for
live broadcast. Therefore these existing streaming schemes is more
applicable to recorded contents viewing that offers a better
experience over slower connections for recorded contents viewer.
Especially, in the case of "Multi-Screen", the service provider
intends to provide a common user experience when the user enjoys the
media content across PCs, TVs, and smart-phones. Therefore, HTTP
streaming over the Internet without some optimization on network
transport for QoE improvement may lead difficulty for the service
provider to comply the service level agreements (SLAs) between
Wu & Huang Expires April 28, 2011 [Page 5]
Internet-Draft HTTP Streaming Problem Statement October 2010
service provider and users.
This document explores problems inherent in HTTP streaming. Several
issues regarding network support for HTTP Streaming have been raised,
which include QoS improvement offering to streaming video over
Internet, efficient delivery, playback control and real time
streaming media synchronization support etc. The following sections
described architecture of HTTP streaming system, introduce related
works and model on HTTP streaming, analyze some use cases in HTTP
streaming and list the potential problems when providing better
streaming quality over the Internet.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Push Model: The model that allows the server keep pushing data
packets to the client.
Pull Model: The model that allows the client keep pulling data
packets from the server.
Live Streaming: Live events can be streamed over the Internet with
the help of broadcast software which encodes the live source and
delivers the resulting stream to the server. The server then
transfers the stream. So the user experiences the event as it
happens.
On-Demand Streaming: To provide "anytime" access to media content,
client is allowed to select and playback on demand.
Progressive Download: A mode that allow client playback the media
file while the file is downloading, after only a few seconds wait
for buffering, the process of collecting the first part of a media
file before playing.
Adaptive Streaming: Adaptive streaming is a process that adjusts the
quality of a video delivered to a client based on the changing
network conditions to ensure the best possible viewer experience.
3. Architecture of HTTP Streaming System
Figure 1 shows reference Architecture for HTTP Streaming in general
Wu & Huang Expires April 28, 2011 [Page 6]
Internet-Draft HTTP Streaming Problem Statement October 2010
case. The Architecture should comprise the following components:
+--Streaming--+ +-Distribution+ +- Client -+
| Component | | Component | | Component |
| +-------+ | | +--------+ | | +------+ |
| | Media | | | | HTTP | | | | HTTP | |
| |Encoder| | | | Proxy/ | | | |Client| |
| +-------+ | | | Server | | | +------+ |
| +---------+ |------->| +--------+ |------>| |
| |Streaming| | | +-------+ | | |
| |Segmenter| |<-------| |Network| |<------|+---------+|
| +---------+ | | | Cache | | ||Streaming||
| +------+ | | +-------+ | || Client ||
| | HTTP | | | +---------+ | |+---------+|
| |Server| | | |Streaming| | | |
| +------+ | | | Engine | | +-----------+
+-------------+ | +---------+ |
+-------------+
Figure 1: Reference Architecture for HTTP Streaming
o Streaming Component
o Distribution Component
o Client Component
3.1. Functions of Streaming Components
+--------------------+----------------------------------------------+
| Function | Role |
+--------------------+----------------------------------------------+
| Media Encoder | Encode the media and encapsulate with |
| | specific streaming formats for delivery |
| - | - |
| Streaming | divide the input media into a series of small|
| Segementer | chunks;Create index file containing reference|
| | to each chunks |
| - | - |
| HTTP Server | handles HTTP request from client and respond |
| | to HTTP connections |
+--------------------+----------------------------------------------+
Figure 2: Functions of Streaming Component
Wu & Huang Expires April 28, 2011 [Page 7]
Internet-Draft HTTP Streaming Problem Statement October 2010
3.2. Functions of Distribution Components
+--------------------+----------------------------------------------+
| Function | Role |
+--------------------+----------------------------------------------+
| Network Cache | Cache the data |
| | |
| - | - |
| Streaming | Distinguish between regular HTTP traffic and |
| Engine | HTTP Streaming Traffic; Enable HTTP Streaming|
| | localized |
| - | - |
| HTTP Proxy/ | Handles HTTP request from client;Forward data|
| Server | to client or respond to HTTP connections |
+--------------------+----------------------------------------------+
Figure 3: Functions of Distribution Component
3.3. Functions of Client Components
+--------------------+----------------------------------------------+
| Function | Role |
+--------------------+----------------------------------------------+
| Streaming | |
| Client | Handle Streaming Playout and Buffer |
| | |
| - | - |
| HTTP | Initialize HTTP Connection |
| Client | |
+--------------------+----------------------------------------------+
Figure 4: Functions of Client Components
4. Existing Work and Model
Based on the architecture described in Section 3, a growing number of
works have been done to build HTTP streaming system with the intend
to provide more streaming characteristics such as URI for media
fragment, media presentation description, playback control etc. Also
how existing HTTP Streaming model(i.e., client pull model) has been
discussed.
4.1. Media Fragments URI
W3C Media Fragments Working Group extends URI defined in [RFC3986]and
specifies some new semantics of URI fragments and URI queries
[MediaFragments] which is used to identify media fragments. The
Wu & Huang Expires April 28, 2011 [Page 8]
Internet-Draft HTTP Streaming Problem Statement October 2010
client can use such Media Fragments URI component to retrieve one
fragment following the previous fragment from the server. However
such component is not extensible to convey more important streaming
information about bandwidth utilization, quality control and buffer
management. Therefore it is a big challenge to use the existing web
infrastructure with such component to deliver streaming contents with
QoE guaranteed.
4.2. Media Presentation Description
[I.D-pantos-http-live-streaming]formerly defines media presentation
format by extending M3U Playlist files and defining additional flags.
3GPP TS 26.234 also centers around media presentation format and
specifies Semantics of Media presentation description for HTTP
Adaptive Streaming [TS26.234], which contains metadata required by
the client(i.e., Smartphone) to construct appropriate URIs
[RFC3986]to access segments and to provide the streaming service to
the user. We refer to this media presentation description as
playlist component. With such component support, client can poll the
new data in chunks one by one. However without client request using
HTTP, the server will not push the new data to the client, therefore
it may not meet the real-time requirements when streaming live media
to clients only relying on client poll model to deliver high quality
streaming contents across the best-effort Internet, especially when
experiencing network transition. More survey on MPD and client pull
model can be found in [GapAnalysis]
4.3. Playback Control on media fragments
W3C HTML5 Working Group has incorporated video playback features into
HTML5 Specification which we refer to as local playback control.
Such local playback capability has been previously dependent on
third-party browser plug-ins. Now HTML5 specification lifts video
playback out of the generic <object> element and put it into
specialized <video> 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 [TS26.234], 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]
4.4. Server Push
W3C Server Sent Push specification defines an API for opening an HTTP
connection for receiving push notifications from a server. However
Wu & Huang Expires April 28, 2011 [Page 9]
Internet-Draft HTTP Streaming Problem Statement October 2010
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.
4.5. Existing HTTP Streaming Model(Client Pull Model)
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.
Streaming +- HTTP -+
+ Server --+ Streaming Client
| | | +------+ |
| +-------+ | HTTP | | HTTP | |
| | Media | | Proxy | |Client| |
| |Encoder| | +------+ +------+ | +------+ |
| +-------+ | | HTTP |------+------+------>| |
|+---------+| |Server|<-----+------+-------| |
||Streaming|| +------+ +------+ |+---------+|
||Segmenter|| ||Streaming||
|+---------+| || Client ||
| | |+---------+|
| | | |
+-----------+ +-----------+
Figure 5: Pull model for HTTP Streaming
5. Analysis of different use cases
5.1. Live Streaming Media broadcast
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
Wu & Huang Expires April 28, 2011 [Page 10]
Internet-Draft HTTP Streaming Problem Statement October 2010
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.
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.
5.2. "Multi-Screen" Service Delivery
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:
Startup delay:
* 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
Wu & Huang Expires April 28, 2011 [Page 11]
Internet-Draft HTTP Streaming Problem Statement October 2010
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.
* 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.
QoE feedback:
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.
5.3. Content Publishing between Servers
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
Wu & Huang Expires April 28, 2011 [Page 12]
Internet-Draft HTTP Streaming Problem Statement October 2010
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.
6. Aspects of Problem
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.
6.1. Inefficient Streaming Content Delivery
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:
o 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.
o 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.
o 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.
o 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
Wu & Huang Expires April 28, 2011 [Page 13]
Internet-Draft HTTP Streaming Problem Statement October 2010
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.
o Client polling may keep waiting for the arrival of data in
response to the previous request before sending the next new
request.
o 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.
Therefore it is desirable to offer better transport for streaming
contents delivery.
6.2. No QoE Guaranteed Support
Due to the lack of QoE guarantee on the packet switching based
Internet, the internet streaming can only provide best effort quality
to consumers.
This may have the following effects that are not desirable:
o 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.
o 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.
o 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.
Wu & Huang Expires April 28, 2011 [Page 14]
Internet-Draft HTTP Streaming Problem Statement October 2010
o 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.
A study conducted by StreamGuard.net examined more than 2,400
different Internet video streams. They concluded that:
o 51% of stream viewers were frustrated with the experience.
o 17% of streams have an immediate fatal error.
o 25% take between 5 and 10 seconds to start playing, and stop to
rebuffer before the video is finished.
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.
6.3. No QoS Control and Feedback Support
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.
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
Wu & Huang Expires April 28, 2011 [Page 15]
Internet-Draft HTTP Streaming Problem Statement October 2010
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.
6.4. No Streaming Content Distribution and Discovery Support
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.
6.5. Lacking Streaming media Synchronization support
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.
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. Currently most
Wu & Huang Expires April 28, 2011 [Page 16]
Internet-Draft HTTP Streaming Problem Statement October 2010
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).
6.6. No Multicast Support
HTTP is sent over TCP and only supports unicast which may increase
processing overhead by 30% in contrast with using multicast
transmission.
6.7. Inadequate Streaming Playback Control
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
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.
Wu & Huang Expires April 28, 2011 [Page 17]
Internet-Draft HTTP Streaming Problem Statement October 2010
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.
7. Scope of the problem
Goal: Develop interoperable solutions that offer more efficient
transport for real time streaming media and allows interoperability
with other existing streaming techniques.
Possible Directions forward:
o Specify how an application running over HTTP should operate in
order to be able to support HTTP streaming and avoid certain
challenges/issues
o Extend websocket protocol to support HTTP Streaming and avoid
certain challenges/issues
o Build a different protocol to HTTP like RTMP for streaming data
o Specify a different transport layer for HTTP to avoid the problems
o Other suggestions from working group via mailing list or ad-hoc
meeting
Possible Models to be built:
Wu & Huang Expires April 28, 2011 [Page 18]
Internet-Draft HTTP Streaming Problem Statement October 2010
7.1. Enhanced HTTP Streaming Pull model
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.
Streaming +-Distribution+
+ Server --+ | Component | HTTP Streaming
| | | +--------+ | +-- Client--+
| +-------+ | HTTP | | HTTP | | HTTP | |
| | Media | |Streaming | | Proxy/ | | Streaming | +------+ |
| |Encoder| | Traffic | | Server | | Traffic | | HTTP | |
| +-------+ |--------->| +--------+ |---------->| |Client| |
|+---------+| | +-------+ | | +------+ |
||Streaming|| | |Network| | | |
||Segmenter||<-------- | | Cache | |<----------| |
|+---------+| Pull | +-------+ HTTP Request|+---------+|
| +------+ | | +---------+ | ||Streaming||
| | HTTP | | | |Streaming| | || Client ||
| |Server| | | | Engine | | |+---------+|
| +------+ | | +---------+ | | |
+-----------+ +-------------+ +-----------+
Figure 6: Enhanced Pull model with involvement of Distribution
Component
7.2. HTTP Streaming Push model
In the push model, there may have one or more than one Distribution
Servers placed between HTTP Streaming Server and HTTP Streaming
Client.
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.
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
Wu & Huang Expires April 28, 2011 [Page 19]
Internet-Draft HTTP Streaming Problem Statement October 2010
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.
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
------------------------------>
Push HTTP Streaming
-------> HTTP Request
<+++++++
Push
-------->
Figure 7: Push model for HTTP Streaming
8. Security Considerations
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.
Wu & Huang Expires April 28, 2011 [Page 20]
Internet-Draft HTTP Streaming Problem Statement October 2010
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.
9. Acknowledgement
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.
10. References
10.1. Normative References
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[TS26.234]
3GPP Standard, "Transparent end-to-end Packet-switched
Streaming Service (PSS);Protocols and codecs (Release 9)",
3GPP TS 26.234 , March 2010.
10.2. Informative References
[RAMS] VerSteeg , B., Begen , A., VanCaenegem, T., and Z. Vax,
"Unicast-Based Rapid Acquisition of Multicast RTP
Sessions", draft-ietf-avt-rapid-acquisition-for-rtp-16
(work in progress), October 2010.
[I.D-pantos-http-live-streaming]
Pantos, R. and W. May, "HTTP Live Streaming", June 2010.
Wu & Huang Expires April 28, 2011 [Page 21]
Internet-Draft HTTP Streaming Problem Statement October 2010
[GapAnalysis]
Zong, N., "Survey and Gap Analysis for HTTP Streaming
Systems", October 2010.
[J.1080] ITU-T, "Quality of experience requirements for IPTV
services", Recommendation ITU T G.1080 .
[I-D.ietf-pmol-metrics-framework-02]
Clark, A., "Framework for Performance Metric Development".
[HTML5] W3C, "HTML5",
http://www.w3.org/TR/html5/video.html#media-elements .
[ServerSentEvent]
W3C, "Server Sent Event",
http://www.w3.org/TR/eventsource/ .
[MediaFragments]
W3C, "Media Fragments", http://www.w3.org/2008/WebVideo/
Fragments/WD-media-fragments-spec/ .
[SmoothStreaming]
Microsoft, "Smooth Streaming", http://blogs.iis.net/
samzhang/archive/2009/03/27/
live-smooth-streaming-design-thoughts.aspx .
Authors' Addresses
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: sunseawq@huawei.com
Rachel Huang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: Rachel@huawei.com
Wu & Huang Expires April 28, 2011 [Page 22]