Subject: [httpstreaming] Current Status and Our Goal

From: Qin Wu <[email-masked]>
Date: Mon, 27 Sep 2010 09:20:26 +0800

Hi, folks:
We have planned to have a BarBOF in time for Beijing IETF meeting. 

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

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

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

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.

Regards!
-Qin

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 26 Sep 2010 19:41:38 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
> Sent: Sunday, September 26, 2010 9:20 PM
> To: [email-masked]
> Subject: [httpstreaming] Current Status and Our Goal
> 
> Hi, folks:

Could we get this scheduled for earlier in the week if possible?
 
> (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.
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.
 
> 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.

> 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.
 
> and thoughts in draft to this discussion list.

Cheers, acbegen.

---

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

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

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

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

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

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

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

Cheers, acbegen.

---

From: Wenbo Zhu <[email-masked]>
Date: Tue, 28 Sep 2010 01:03:55 -0700

Thanks for putting all these together, and I definitely see the value in
standardizing media streaming semantics on top of HTTP.

A few meta-comments related to the subject of "HTTP streaming"
1. focus on HTTP and exclude any ambiguity that a different transport may be
considered;
2. make it clear that this work is agnostic to emerging Web protocols/specs
that are fundamentally browser-oriented;
3. avoid any attempt to extend the basic HTTP semantics (e.g. in conflict
with httpbis)

- Wenbo

On Sun, Sep 26, 2010 at 6:20 PM, Qin Wu <[email-masked]> wrote:

> (http://www.ietf.org/mail-archive/web/httpstreaming/current/msg00002.html)
> which was raised by people who are interested
> (
> http://www.ietf.org/internet-drafts/draft-wu-http-streaming-optimization-ps-01.txt
> ).
>
> Also I would like to point out some related works in IETF for your
> references. Curretly what we have on the table includes:
> If there is any related work missing or wrong, please let me know. Also I
> would like to encourage people to bring your contributions
> _______________________________________________
> httpstreaming mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/httpstreaming
>
>

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 29 Sep 2010 14:59:09 -0400

So we have had a number of threads, some about possible work, some
about details in the charter, etc. I think it is great to start
thinking about a possible charter if this work turns into a WG, and
some good reference drafts (thanks to Qin and the folks from Apple for
putting these together), but I think another way to look at this might
be to at least initially take a step back and see if the folks on the
list can take a stab at some more basic questions. I think that was
perhaps what Qin was getting at when we started this thread, but it is
always good to refocus.

I'll ask two really basic questions to the folks on list, and let's
see what the opinions may be, and maybe we can move forward from
there. Personally, I think that if we have a bar BoF, focusing just on
these two basic questions (ok, one is a compound question, but one is
basic!) might be a good way to move forward. I expect we'll have some
VERY different answers. Remember that HTTP streaming may mean
different things to people, and might even be the wrong term...but
these are the things we need to try to figure out.

So the two big questions:

1) On the topic of this list/HTTP streaming, what do you think is the
problem/problems/scenario we should be looking at?

2) What other standards body work in this space are you aware of
(including IETF work), and how do you think any new work would fit in
(or not!) with the answer above?

Yep, these are really broad, but to me, they seem to be at the heart
of what we need to figure out to move forward. I think that at the
beginning of this thread these were the basic questions Qin was
looking to answer, and I think they are a great place to start.

David

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 30 Sep 2010 18:13:08 +0100

David, Colleagues,

> perhaps what Qin was getting at when we started this thread, but it is

Ah! I (wrongly) assumed that the areas of possible work were already known to someone and the proposed charter was just an attempt to articulate them.

> problem/problems/scenario we should be looking at?

I do not feel I am in a position just yet to start making statements about what problems I think a HTTP streaming group (if formed) should look at, however one area that I think may be interesting to study and that I am not aware of other bodies looking at is "chunk hints".

A lot of streaming media today is delivered via CDNs that operate as more than just a dumb (inline) proxy cache.

HTTP naturally supports the insertion of caches transparently to the end points so one could argue that nothing more needs to be done for HTTP streaming than for regular HTTP.

As adaptive bit rate combined with HTTP delivery relies on throughput measurements to determine the appropriate bit rate to download for subsequent chunks, variation in latency (e.g. the difference between a request for a chunk being a cache hit Vs a cache miss) is likely to affect the throughput perceived by the client and therefore may cause bit rate switch on a cache miss that wouldn't have occurred had the request actually been a cache hit.

If there was some way to provide a "hint" to the server/cache as to which chunk the client is likely to request next then a CDN could elect to retrieve that chunk ahead of it actually being requested to keep the response latency (or some other factor) more consistent and avoid additional bit rate switches.

> (or not!) with the answer above?

None that I am aware of.

---

From: "Luby, Michael" <[email-masked]>
Date: Thu, 30 Sep 2010 12:15:03 -0700

One thing I suggest is that this group seriously study DASH standardization
work in 3GPP and MPEG to understand what these standards do and do not
address, preferably before deciding whether or not to start a group and
definitely before establishing a charter if the decision is to start a
group.

On 9/30/10 10:13 AM, "Ben Niven-Jenkins" <[email-masked]> wrote:

> Ah! I (wrongly) assumed that the areas of possible work were already known to
> someone and the proposed charter was just an attempt to articulate them.
> 
> I do not feel I am in a position just yet to start making statements about
> what problems I think a HTTP streaming group (if formed) should look at,
> however one area that I think may be interesting to study and that I am not
> aware of other bodies looking at is "chunk hints".
> 
> HTTP naturally supports the insertion of caches transparently to the end
> points so one could argue that nothing more needs to be done for HTTP
> streaming than for regular HTTP.
> 
> As adaptive bit rate combined with HTTP delivery relies on throughput
> measurements to determine the appropriate bit rate to download for subsequent
> chunks, variation in latency (e.g. the difference between a request for a
> chunk being a cache hit Vs a cache miss) is likely to affect the throughput
> perceived by the client and therefore may cause bit rate switch on a cache
> miss that wouldn't have occurred had the request actually been a cache hit.
> 
> If there was some way to provide a "hint" to the server/cache as to which
> chunk the client is likely to request next then a CDN could elect to retrieve
> that chunk ahead of it actually being requested to keep the response latency
> (or some other factor) more consistent and avoid additional bit rate switches.
> 
> 
>

---

From: Daniel Park <[email-masked]>
Date: Fri, 1 Oct 2010 11:03:13 +0900

That's what I pointed out at the previous mail.

"gap analysis among the existing approaches"

For example, a new design team (or study team) can be formed together in
this group. It's very general process within IETF to harmonize different
voices.

Daniel @ Samsung

On Fri, Oct 1, 2010 at 4:15 AM, Luby, Michael <[email-masked]> wrote:

> > A lot of streaming media today is delivered via CDNs that operate as more
> than
> > just a dumb (inline) proxy cache.
> >

-- 
Soohong Daniel Park
Samsung Electronics, DMC R&D
http://www.soohongp.com, twitter:@natpt