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

[Francois Le Faucheur <[e-mail]>]

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
  transmission.
"
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...).


* 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.


* 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 )?

Cheers

Francois


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

> Hi
> 
> An updated version of 
> http://www.ietf.org/internet-drafts/draft-wu-http-streaming-optimization-ps-03.txt
> 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: <[e-mail]>
> To: <[e-mail]>
> 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:
>> http://www.ietf.org/internet-drafts/draft-wu-http-streaming-optimization-ps-03.txt
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[e-mail]
Phone: [phone]
Mobile: [phone]



Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

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:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html