W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

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

From: Ning Zong <zongning@huawei.com>
Date: Thu, 04 Nov 2010 00:30:28 +0000
To: 'Mark Nottingham' <mnot@mnot.net>, 'HTTP Working Group' <ietf-http-wg@w3.org>
Cc: 'Qin Wu' <sunseawq@huawei.com>, "'David A. Bryan'" <dbryan@ethernot.org>
Message-id: <005801cb7bb7$59f8cba0$3a298a0a@china.huawei.com>
Hi, Mark,

Thank you for your interests and feedback.
I will get back to your concern soon after my current IETF slides work. :))
And we hope to see you in HTTP streaming bar BoF on next Wednesday for more

Ning Zong

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Wednesday, November 03, 2010 5:58 PM
To: HTTP Working Group; zongning@huawei.com
Subject: Fwd: I-D Action:draft-zong-httpstreaming-gap-analysis-01.txt

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:

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:

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


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
> 	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:
> 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.
Received on Thursday, 4 November 2010 07:00:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC