[httpstreaming] Charter Skeleton draft- Your thoughts are requested

Qin Wu <sunseawq@huawei.com> Sat, 25 September 2010 04:04 UTC

Return-Path: <sunseawq@huawei.com>
X-Original-To: httpstreaming@core3.amsl.com
Delivered-To: httpstreaming@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 577A43A6886 for <httpstreaming@core3.amsl.com>; Fri, 24 Sep 2010 21:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.491
X-Spam-Level: **
X-Spam-Status: No, score=2.491 tagged_above=-999 required=5 tests=[AWL=-2.252, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 11cI5u-Aqppu for <httpstreaming@core3.amsl.com>; Fri, 24 Sep 2010 21:04:44 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown []) by core3.amsl.com (Postfix) with ESMTP id D747A3A68D9 for <httpstreaming@ietf.org>; Fri, 24 Sep 2010 21:04:43 -0700 (PDT)
Received: from huawei.com (szxga04-in []) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9A00IF9BCHIK@szxga04-in.huawei.com> for httpstreaming@ietf.org; Sat, 25 Sep 2010 12:05:06 +0800 (CST)
Received: from huawei.com ([]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9A00GMDBCHA6@szxga04-in.huawei.com> for httpstreaming@ietf.org; Sat, 25 Sep 2010 12:05:05 +0800 (CST)
Received: from w53375 ([]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9A003B6BCH5X@szxml06-in.huawei.com> for httpstreaming@ietf.org; Sat, 25 Sep 2010 12:05:05 +0800 (CST)
Date: Sat, 25 Sep 2010 12:05:05 +0800
From: Qin Wu <sunseawq@huawei.com>
To: httpstreaming@ietf.org
Message-id: <02f501cb5c66$d61b15f0$4f548a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: multipart/alternative; boundary="Boundary_(ID_fc7v+0hkr/dxwb7mZdo9ag)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [httpstreaming] Charter Skeleton draft- Your thoughts are requested
X-BeenThere: httpstreaming@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming>
List-Post: <mailto:httpstreaming@ietf.org>
List-Help: <mailto:httpstreaming-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Sep 2010 04:04:46 -0000

Hi, folks:
Sorry for late reply for three-days Chinese Holiday.
As I pointed out at the previous email, I  would like to share our thoughts on what the new charter looks like. 
Here is  the initial version of Charter Skeleton I drafted.Your feedback would be highly useful and appreciated at this point.

Moreover, I think we need to be thinking about what work will be accepted
under this charter, and are there any missing part that needs to be taken into account.


Focus on work which will address relevant issues facing the network operator community today.
In particular an effort will be made to address gaps and issues in currently understood best practices for
forwarding, control plane, and management plane and seek network capability to control and manage HTTP Streaming.

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. 

Since HTTP streaming takes Existing HTTP as data transport (i.e., HTTP 1.1) and 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.One way to reduce major packet drop-outs is to 

introduce media segmentation capability in the network behind media encoder, i.e., using segmenter to split the input 

streaming media into a serial of small chunks and meanwhile creating manifest file containing reference to each chunks. 

Allowing such streaming media segmentation can mitigate great delays and breakups during streaming playout.

Why HTTP Streaming:

As the HTTP protocol is widely used on the Internet as data transport, it has since been employed extensively for the delivery of multimedia content. A significant part of the

 Internet traffic today formly generated by P2P application has been eclipsed by streaming, CDN and direct download. 

Another trend is the growing popularity of connected devices like Smartphones, TVs, PCs and tablets is raising interest 

in multi-screen services that enable consumers to access the same media content and quality of experience (QoE) on any 

device, anytime and anywhere. Since almost all the connected devices have browser support, but not all of them can 

afford high CPU load and batteries draining as TVs or PCs, it is obviously a best choice to use HTTP streaming to 

support multi-screen video delivery. 

Problems: (The challenging of the existing work on HTTP streaming)

With media segmentation support, existing streaming technology (e.g., progressive download streaming) 

is characterized as client based pull schemes and more relies on client to handle buffer and playback during 

download. However streaming long duration and high quality media over the internet has several unique Challenges:

¨C    Client polling for each new data in chunks using HTTP requests is not efficient to deliver high-quality video content across the Internet

¨C    Segmentation capability requires over-utilizing CPU and bandwidth resources, which may not be a desirable and effective way to improve the quality of streaming media delivery

¨C    Lack of QoS guarantee on the packet switching based Internet , the quality of Internet media streaming may significant degrade due to rising usage 

¨C    Experience burstiness or other dynamics changes due to bandwidth fluctuations and heterogeneous handover.

¨C    Impossible to fast-forward through any part of a streaming contents until it is stored on the user's device

Given these challenges, the typical user experience can be limited by delayed startups, poor quality, buffering delays, and inadequate playback control.


a. Exploration of problem inherent in HTTP streaming.

b.Proposals for new approaches to operational challenges metioned above.
In order to address those above challenges effectively , the group may consider to design and specify  

network based HTTP Streaming schemes/protocol that will offer efficient and network-friendly transport 

with QoS/QoE guaranteed and the feedback on quality of data delivery. HTTP Streaming applications can rely

 on the server side to detect the user's connection speed and select the streaming contents with the appropriate

 encoding rate for smooth, uninterrupted playback. Also it can choose to switch between push or pull using the 

better transport.

As a simple example, the server keeps on pushing data chunks to the client and the client communicates 

with the server over a full-duplex TCP connection to convey feedback on quality of data delivery. And then the server 

tunes the parameters such as buffer size and bandwidth according to QoS feedback and network load. In case of streaming 

changes or failover, the server may send notification event to the client. Though there are existing server push schemes 

(e.g., Server Sent Event, XMLHttpRequest, iFrame,WebSocket), however they might be lack capability for 

providing feedback on quality of data delivery.

Playlist format and Streaming file format should be beyond scope of this charter.