Re: [httpstreaming] Current Status and Our Goal

[Qin Wu <[e-mail]>]

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[e-mail]>
To: "Qin Wu" <[e-mail]>; <[e-mail]>
Sent: Monday, September 27, 2010 10:41 AM
Subject: RE: [httpstreaming] Current Status and Our Goal



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Qin Wu
> Sent: Sunday, September 26, 2010 9:20 PM
> To: [e-mail]
> Subject: [httpstreaming] Current Status and Our Goal
> 
> Hi, folks:
> We have planned to have a BarBOF in time for Beijing IETF meeting.

Could we get this scheduled for earlier in the week if possible?

[Qin]: Good idea. But is it too early to schedule this meeting? formerly I was  planning to ask people to vote on the meeting time
two or three weeks before Beijing IETF meeting. And we may take advantage of Doodle to do this.
 
> The primary goal of this BarBOF is to making sure that people agree on what problem (or problems) need to be solved;
> Some of these problems or interesting issues are summarized in my previous email available at
> (http://www.ietf.org/mail-archive/web/httpstreaming/current/msg00002.html) which was raised by people who are
> interested
> in HTTP Streaming in the  DISPATCH mailing list before we move to this new discussion list.
> The other problems come from HTTP streaming Problem statement
> draft which I have updated recently
> (http://www.ietf.org/internet-drafts/draft-wu-http-streaming-optimization-ps-01.txt).

I have two major comments on this draft:
1- There is an acronym pollution which results from referring to several different specifications at the same time. I strongly suggest to have a definitions section and simply adopt the definitions from the most mature spec, which is the 3gpp spec as of now.

[Qin]: Yes, you are right. e.g.,"media fragments" specified in W3C takes the name of "media segments" in 3GPP, "playlist" specified in Apple's live streaming draft is referred to as "media description presentation",Also "medias description presentation" will be described as "manifest". Also we have different name for HTTP streaming,
HTTP adaptive streaming, HTTP smooth streaming, HTTP live streaming, Dyanmic HTTP Streaming. It is very confusing what they are and what's their difference. 
Therefore we will clearup these acronym polution in the new version.

2- There are many strong claims which (mostly) favor HTTP streaming compared to other approaches. I can understand the bias, however, I would recommend staying away from making claims without proper proof or citation. This will help us have a more fair problem statement document.

[Qin]: Thank for your suggestions, we will add some concrete citations to convince this in the new version.
Yes, actually we have had proofs and statistics data.e.g.,
a. According to ATLAS Internet observatory 2009 annual report, P2P is the fastest shrinking, and mainly eclipsed by streaming, CDN and direct download.
b. According to another report  about Global Mobile Broadband Traffic Report from Allot communications, HTTP streaming is the fastest growing application with a rise of above 50%
you might be interested in taking looking at this https://files.me.com/alexander.adolf/ib9f1x which has been become available recently.

 
> Another goal is to make sure we have not any overlapping with other SDO.

We *can* certainly have an overlapping goal, why should not we if we decide to move forward? If we think we have a better solution for a problem, we should propose and document it. There is indeed a timing issue since other groups have started working on this long before. But, if needed, we can catch up quickly.

[Qin]: I would like to say it is better for us to take other SDO's work as basis and make gap analysis between what IETF is going to do and what other SDO has already done to make them comfortable. And I am pretty much sure there are too much room for IETF to delve into.
e.g., Existing work more rely on Client to handle bandwidth and playout and require nothing from network side which is diffcicult to satisfy QoS/QoE requirement which Best effort Internet can not provide.  

> In order to stimulate the discussion toward these two goals, I have crafted intial charter skeleton.
> http://www.ietf.org/mail-archive/web/httpstreaming/current/msg00003.html

That is a pretty loaded charter. I hope the mailing list discussion will get us to a better position before the meeting.

[Qin]: yes, we definitely need to narrow the scope and gain an understanding of the directions forward through this list discussion.
The charter text I proposed is just used for discussion basis. If you have any thoughts/ideas on our goal and scope of charter text,
please speakup and share your thoughts. 
 
> I would like us to center around these problems we listed and the intial charter skeleton I drafted to figure out
> (a) what kind of use cases can we  have
> (b) and how many problems are worth being discussed
> (c) Is there any challenging issues we missed or neglected?
> (d) and what kind of concrete protocol/mechanism/scheme can we  come up with?
> 
> Also I would like to point out some related works in IETF for your references. Curretly what we have on the table includes:
> Apples' HTTP live streaming
> http://tools.ietf.org/html/draft-pantos-http-live-streaming-04
> HTTP Streaming Problem Statement
> http://tools.ietf.org/html/draft-wu-http-streaming-optimization-ps-001
> Implications of Full-Duplex HTTP
> http://tools.ietf.org/html/draft-zhu-http-fullduplex-01
> If there is any related work missing or wrong, please let me know. Also I would like to encourage people to bring your
> contributions
> and thoughts in draft to this discussion list.

Cheers, acbegen.
 
> Regards!
> -Qin