Re: [httpstreaming] Why a new standard for streaming HTTP?

Mike-

Excellent points. IMHO, IETF should take the other SDO's work as a
baseline. Then, and only the, should the IETF determine if there is
anything we can contribute. 

One area that may be productive is in how a high-concurrency stream
(think World Cup Finals) could be efficiently delivered. The current
unicast caching methods are all fine and good, but if we try to extend
them to cover very high concurrency cases for rate adaptive flows, I
suspect that we will be out of bandwidth, particularly in the last mile.
I suspect that a multicast solution would have some merit. There is a
small bit of work being done in this area at the other SDOs, but I
suspect that some of the subject matter experts are at the IETF. I
further suspect that the other SDOs recognize that this is an important
area that needs to be done properly, and would welcome some good ideas
from the IETF.

There may be other areas, but let's be real sure that we pick our spots
judiciously. We have enough on our plates without making work for
ourselves.

Bill VerSteeg

From: httpstreaming-bounces@ietf.org
[mailto:httpstreaming-bounces@ietf.org] On Behalf Of Luby, Michael
Sent: Monday, September 27, 2010 4:35 PM
To: httpstreaming@ietf.org
Cc: Luby, Michael
Subject: [httpstreaming] Why a new standard for streaming HTTP?

A few comments/thoughts.

(1) The SDOs that are already deeply involved in standardizing OTT HTTP
streaming have worked hard to stay aligned, e.g., 3GPP, MPEG, OIPF.
There is a lot of ongoing coordination between these organizations on
HTTP streaming (DASH - dynamic adaptive streaming over HTTP), many of
the people involved are working across these organizations, and liaisons
are being sent back and forth to coordinate, etc.  For example, they
have all adopted the same baseline standard that was initiated in 3GPP,
and features that were developed by MPEG are being rolled back into
3GPP, etc.  It is not clear what the IETF adds in this sense (or perhaps
may subtract?)  The attempt is to create one standard across the
different organizations, and not disparate competing standards.

(2) If there is any effort in this area by the IETF, it would be good to
align with the goal of one common standard.  If there is fragmentation,
it will not be good for deployment.  For example, I've seen emails on
this list that suggest that the IETF might go in a different direction
and use a different basis other than HTTP, or do something that is based
on HTTP but is contrary to these other standards, and it seems that
these directions will only confuse/slow down any adoption.

(3) If the IETF decides to go off in a different direction and not use
HTTP 1.1 as the basis, to avoid confusion it would be really helpful not
to call this HTTP streaming, but instead call it some other name that is
suitable for whatever is being standardized.

Mike Luby

On 9/27/10 12:00 PM, "httpstreaming-request@ietf.org"
<httpstreaming-request@ietf.org> wrote:

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/httpstreaming

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send httpstreaming mailing list submissions to
 httpstreaming@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
 https://www.ietf.org/mailman/listinfo/httpstreaming
or, via email, send a message with subject or body 'help' to
 httpstreaming-request@ietf.org

You can reach the person managing the list at
 httpstreaming-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of httpstreaming digest..."