Re: [httpstreaming] HTTP Streaming Problem Statement Updating//Re: I-D Action:draft-wu-http-streaming-optimization-ps-03.txt

Qin Wu <> Tue, 09 November 2010 14:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E4793A6820 for <>; Tue, 9 Nov 2010 06:50:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.229
X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[AWL=-1.528, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bPxS4xpo79Fz for <>; Tue, 9 Nov 2010 06:50:56 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id C10873A681F for <>; Tue, 9 Nov 2010 06:50:55 -0800 (PST)
Received: from (szxga04-in []) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Tue, 09 Nov 2010 22:51:19 +0800 (CST)
Received: from ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Tue, 09 Nov 2010 22:51:19 +0800 (CST)
Received: from jys1037603 ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <>; Tue, 09 Nov 2010 22:51:19 +0800 (CST)
Date: Tue, 09 Nov 2010 22:51:29 +0800
From: Qin Wu <>
To: Francois Le Faucheur <>
Message-id: <>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
References: <> <068b01cb743c$89646930$> <>
Subject: Re: [httpstreaming] HTTP Streaming Problem Statement Updating//Re: I-D Action:draft-wu-http-streaming-optimization-ps-03.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Nov 2010 14:50:57 -0000

----- Original Message ----- 
From: "Francois Le Faucheur" <>
To: "Qin Wu" <>
Cc: "Francois Le Faucheur" <>om>; <>
Sent: Tuesday, November 09, 2010 2:49 PM
Subject: Re: [httpstreaming] HTTP Streaming Problem Statement Updating//Re: I-D Action:draft-wu-http-streaming-optimization-ps-03.txt

Hi Qin,

A few comments on the problem statement (haven't gone through all the messages so apologies if there are duplicates):

* one point that comes up multiple times is the concern for live about having to update the manifest file very frequently. Some existing HTTP adaptive streaming schemes support Live today with infrequent update of the Manifest file (i.e. updating it ahead of segment encoding). So it would be useful to clarify why such infrequent update approaches are excluded (i.e. because you want to signal Random Access Points).

* the multicast case is one where I can see significant room for improvement. But there is only very brief discussion about this. For example section 6.6 says:
"HTTP is sent over TCP and only supports unicast which may increase
   processing overhead by 30% in contrast with using multicast
I am not sure where the 30% is coming from, but more importantly I would suggest to bring up the efficiencies that could be obtained by using multicast in the presence of bottlenecks that are shared by users streaming the same Live content (eg Cable access, PON access, link to DSLAMs, home networks...).

[Qin]: Okay, such rephasing seems more make sense. 

* in "7.1.  Enhanced HTTP Streaming Pull model" 
" 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.
I'd suggest making the possible interactions between the Distribution Component and the client more open/flexible/generic. ie a hint from the client to Distribution component is one example of things that may be exchanged. Another example could be that the server provides hints to the client.

[Qin]: Good point, I take it.

* In the reference architecture (Figure 1), inside the "Client Component" have you considered showing the "Streaming Client" above the "HTTP Client" - as opposed to underneath- (in the sense that the client component consumes the data received by the HTTP client )?

[Qin]: Right, I am not assuming Streaming Client should be underneath of HTT Client. They could be in parallel or Streaming Client is above of HTTP Client.
Thank for pointing out this.



On 25 Oct 2010, at 20:02, Qin Wu wrote:

> Hi
> An updated version of 
> is submitted which 
> * address lots of comments from this list 
> * incorporate many concrete  inputs from the list
> Many thanks to those people who have shared their ideas and proposals.
> Comparing with the previous version, the new version  has been thoroughly restructured and organized based on the suggestions on the list.
> The concept would be to center around three typical HTTP Streaming use cases, explore couples of typical problems inherent in the existing
> HTTP streaming model and outline the potential scope of the problem including possible direction forward and possible two new models.
> Hopefully we can define more and more clear scope of the problem.
> If you have any other suggestions and good ideas/ inputs/proposals, please let us know or speakup on the list.
> Regards!
> -Qin
> ----- Original Message ----- 
> From: <>
> To: <>
> Sent: Monday, October 25, 2010 7:15 PM
> Subject: I-D Action:draft-wu-http-streaming-optimization-ps-03.txt
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> Title           : Problem Statement for HTTP Streaming
>> Author(s)       : Q. Wu, R. Huang
>> Filename        : draft-wu-http-streaming-optimization-ps-03.txt
>> Pages           : 22
>> Date            : 2010-10-25
>> 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.
>> A URL for this Internet-Draft is:
>> Internet-Drafts are also available by anonymous FTP at:
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
> --------------------------------------------------------------------------------
>> _______________________________________________
>> I-D-Announce mailing list
>> Internet-Draft directories:
>> or
> _______________________________________________
> httpstreaming mailing list


> Francois Le Faucheur
> Distinguished Engineer
> Corporate Development
> Phone: +33 49 723 2619
> Mobile: +33 6 19 98 50 90
> Cisco Systems France
> Greenside
> 400 Ave de Roumanille
> 06410 Sophia Antipolis
> France


 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins - Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 ?, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to: