Fwd: I-D Action:draft-zong-httpstreaming-gap-analysis-01.txt

From: Mark Nottingham <mnot@mnot.net> · Date: Wed, 3 Nov 2010 20:57:30 +1100

I wanted to bring this draft to the attention of the list, as I think it's some of the better and more complete work I've seen in an area that seems to be interesting to a lot of people these days:
  http://www.ietf.org/internet-drafts/draft-zong-httpstreaming-gap-analysis-01.txt

My specific feedback:

Overall this is comprehensive and helpful in moving the discussion forward. Please continue!

It may be useful to further separate the "real-time" / "live" streaming case from others, as it most likely requires a different approach (as noted in the draft). If you're not already aware of it, you should have a look at the results of the Realtime Web workshop, as well as the ongoing discussion: <http://rtc-web.alvestrand.com/>.

While it appears that all of the approaches you cover are compatible with "generic" HTTP, I wonder how compatible they are in the details. For example:
  a) is it possible to serve video for each using only a "vanilla" HTTP server like Apache or IIS, without any extra modules or server-side scripts? Setting headers and serving files from the filesystem is fine, as is having a process that writes the files to the filesystem for you.

  b) how compatible is each approach with off-the-shelf HTTP caches? E.g., if there's significant variance in the URIs (because of dynamic parameters being passed in), it'll "bust" the cache and lower the hit rate. I know that most of them are not using HTTP range requests; it would be interesting to explore this a bit more.

It would also be very helpful to see examples of the actual HTTP messages (with headers and bodies) used by the various approaches, to give a better idea of how they use the protocol. 

Regarding the lack of QoE improvement and monitoring (in "Challenges"), my interest is in what can be done by clients to minimise delay, quantify the quality of the connection, and adapt without coordination with the server. Adding server hints to responses would be helpful too, of course, but I suspect that a lot more can be done on the client side (perhaps without standardisation; documenting best practices may be enough).

Cheers,

Begin forwarded message:

> From: Internet-Drafts@ietf.org
> Date: 25 October 2010 10:00:02 PM AEDT
> To: i-d-announce@ietf.org
> Subject: I-D Action:draft-zong-httpstreaming-gap-analysis-01.txt 
> Reply-To: internet-drafts@ietf.org
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Survey and Gap Analysis for HTTP Streaming Standards and Implementations
> 	Author(s)       : N. Zong
> 	Filename        : draft-zong-httpstreaming-gap-analysis-01.txt
> 	Pages           : 23
> 	Date            : 2010-10-25
> 
> With the explosive growth of the Internet usage and increasing demand
> for multimedia information on the web, media delivery over Internet
> attract substantial attention from media industry.  To meet above
> requirements, HTTP Streaming technology is designed and gradually
> plays an important role in recent years.  Several leading Standard
> Development Organizations (SDOs) have been producing a series of
> technical specifications to define streaming over HTTP.  Moreover,
> several companies have devoted to developing private HTTP-based media
> delivery platform to provide high quality, adaptive viewing
> experience to customers.  Following a brief survey of existing HTTP
> streaming standards and implementations, this document gives a brief
> summary on these related work, analyzes the potential challenges
> especially from the network point of view, and lists the gap between
> existing work and possible working scope on the topic of HTTP
> streaming in IETF.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-zong-httpstreaming-gap-analysis-01.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.

Attachments