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

[Qin Wu <[e-mail]>]

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

  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
   [e-mail]

  You can reach the person managing the list at
   [e-mail]

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



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


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