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

From: "Luby, Michael" <[email-masked]>
Date: Mon, 27 Sep 2010 13:34:51 -0700

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, "[email-masked]" <[email-masked]> 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
 [email-masked]

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
 [email-masked]

You can reach the person managing the list at
 [email-masked]

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

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 27 Sep 2010 16:38:20 -0400

> (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 org…

Dear Michael;

How aligned is this work with what Apple is doing ?

Regards
Marshall

> _______________________________________________
> httpstreaming mailing list
> [email-masked]

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Mon, 27 Sep 2010 16:21:20 -0500

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Luby, Michael
Sent: Monday, September 27, 2010 4:35 PM
To: [email-masked]
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, "[email-masked]"
<[email-masked]> wrote:

---

From: Qin Wu <[email-masked]>
Date: Tue, 28 Sep 2010 10:59:27 +0800

[httpstreaming] Why a new standard for streaming HTTP?Bill:
You are absolutly right, with the rising usages, the quality of Internet media and network performance will be great challenged and more likely to degrade due to running out bandwdith.
Nowdays HTTP streaming usage is forseen to increase more and more, somewhat due to Olympic Games, US president elections and World Cup Socer. With more and more network connections from
millions of people, I am pretty much doubt how the network with existing approach can handle this, what about bottleneck for these network connections, what about bandwidth saturation? How to guarantee 
the quality of Experience when growing popularity of multiple screen service?

Regards!
-Qin
  ----- Original Message ----- 
  From: Bill Ver Steeg (versteb) 
  To: Luby, Michael ; [email-masked] 
  Sent: Tuesday, September 28, 2010 5:21 AM
  Subject: 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: [email-masked] [mailto:[email-masked]] On Behalf Of Luby, Michael
  Sent: Monday, September 27, 2010 4:35 PM
  To: [email-masked]
  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.

  Mike Luby

------------------------------------------------------------------------------

---

From: Qin Wu <[email-masked]>
Date: Tue, 28 Sep 2010 11:11:35 +0800

[httpstreaming] Why a new standard for streaming HTTP?Hi,
Following the issues raised by Bill, in my memory, it seems some people raised 
one very similar problem in the DISPATCH mailing list when we discuss there,

 i.e,How to make HTTP streaming work in the environment that may use a combination 
of RTP multicast and HTTP unicast?

I think this problem is very interesting, becos Multicast audio and video streams are 
today commonplace in certain parts of the Internet. The vast majority of Internet users,
 however, are not able to take part of multicast streams because they either  lack multicast 
network connectivity, are located behind firewalls, or  have insufficient network resources
 available.

So how to solve this problem, one possible way is to build one RTP to HTTP gateway that 
makes it possible for an Internet user to take  part of multicast video streams. WebSmile is 
one example of RTP to HTTP gateway which can be used to connect to a multicast capable network. 
You may be interested in taking a look at http://www10.org/cdrom/papers/pdf/p387.pdf.

Any thoughts?

Regards!
-Qin
  ----- Original Message ----- 
  From: Bill Ver Steeg (versteb) 
  To: Luby, Michael ; [email-masked] 
  Sent: Tuesday, September 28, 2010 5:21 AM
  Subject: Re: [httpstreaming] Why a new standard for streaming HTTP?

  Mike-

  Bill VerSteeg

  A few comments/thoughts.

  Mike Luby