Re: [httpstreaming] Current Status and Our Goal

[Mark Watson <[e-mail]>]

All,

I would like to add my support to the comments below. Specifically, I think if the IETF considers work in this area it should focus on the HTTP and TCP protocols. Any such work may not be specific to HTTP-streaming (i.e. enhancements that are at first motivated by HTTP Streaming may have broader applicability, and this should be carefully considered).

In the draft I do not see a clear or correct identification of the problems. For example in the introduction the following are stated as issues:

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

MW: Several companies, including my employer, are successfully operating large scale HTTP streaming systems that do efficiently deliver high-quality video content across the Internet, so reality seems to refute this statement.

   - 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

MW: It is not clear that segmentation per se is CPU-intensive or has any non-negligable effect on bandwidth usage.

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

MW: An alternative view is that where quality is degraded due to congestion this is due to lack of bandwidth, rather than a lack of QoS guarantees. Adaptive HTTP streaming systems adjust the video quality to the available bandwidth in order to avoid rebuffering events. It is the available bandwidth that needs to be improved to improve quality.

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

MW: We have found that adaptive HTTP streaming algorithms are well able to cope with bandwidth fluctuations.

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

MW: This is simply not correct, since there are hundreds of examples of devices which support trick-play using HTTP streaming techniques without storing the whole content on the users device.

A first step in considering what, if any, work should be done here might be to contact those organizations which are standardizing the higher layers of HTTP streaming systems (e.g. manifest and file formats) and ask whether there are deficiencies they see in IETF protocols that could be usefully addressed by the IETF. What I think we should avoid in the IETF is duplicating the work of these other bodies.

Best,


Mark Watson

Netflix Inc.




On Oct 10, 2010, at 12:43 AM, Ali C. Begen (abegen) wrote:



-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Lars Eggert
Sent: Friday, October 08, 2010 4:17 PM
To: Colin Perkins
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [httpstreaming] Current Status and Our Goal

On 2010-10-7, at 14:16, Colin Perkins wrote:
There are clearly some issues to consider here. What seems to be
missing from the discussion to me though, is some identification of
the concrete problems. What protocol pieces do we need, but not have?
What protocols are problematic, and need enhancement? Is there
protocol work to do in IETF, or should we be documenting best current
practices for using the existing protocols and/or relying on other
bodies to fill the gaps?

The draft-wu-http-streaming-optimization-ps is a good start at such an
analysis, but doesn't go deep enough to let us decide what work IETF
should do.

+1

The key question really is "what do you think the IETF needs to do?"

I imagine the only work the IETF should do (if we decide to) is the transport and HTTP-layer optimization for better streaming performance.

-acbegen

Lars
_______________________________________________
httpstreaming mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/httpstreaming