Subject: Re: [httpstreaming] Current Status and Our Goal

From: Roni Even <[email-masked]>
Date: Wed, 06 Oct 2010 23:56:12 +0200

Hi,
I think that David first question is important and here is my view

Roni Even

> 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?

My view is that we are trying to address the transport of media in HTTP both
pre-recorded and live. The major issues I see are

1. Address the issue of allowing both push and pull models (addressing the
use cases and concerns from Qin draft) 
2. Address the startup issue, we have worked in AVT on fast channel/content
change and I think this is relevant also in this case.
3. Look at the scaling problem when there is no multicast or broadcast
support.

In general I think that by having a use cases document that covers the
scenarios that look important to the group we can achieve a better
understanding of what is the charter of the work. 

> 
> 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: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 6 Oct 2010 15:14:54 -0700

> change and I think this is relevant also in this case.

Are you assuming a multicast environment for http streaming? Ow, the startup issue is not an issue in unicast connections.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Thu, 07 Oct 2010 00:26:11 +0200

Ali,
It is not the same as multicast but is still a problem for live streaming
when buffering is used on the server that  may delay the data and there is
also a need for video synchronization to start rendering.
For pre-recorded video this may be due to distance between synchronization
points and the size of a chunk sent.
Roni Even

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Thursday, October 07, 2010 12:15 AM
> To: Roni Even; David A. Bryan; Qin Wu
> Cc: [email-masked]
> Subject: RE: [httpstreaming] Current Status and Our Goal
> 
> Are you assuming a multicast environment for http streaming? Ow, the
> startup issue is not an issue in unicast connections.
> 
> -acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 6 Oct 2010 15:40:08 -0700

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, October 07, 2010 6:26 AM
> To: Ali C. Begen (abegen); 'David A. Bryan'; 'Qin Wu'

Sure, http streaming or streaming over another protocol will always be delayed. The content generation, pushing it to the source servers and CDN and then getting them to the clients plus the playout buffers will add up a delay of 20-30 seconds compared to regular over-the-air broadcast. 

I don't think there is much we can do about this, especially in the IETF.

> also a need for video synchronization to start rendering.

Synchronization among the viewers you mean? That could be a concern but seriously, since client implementations will differ, network capacities will differ, i.e., pretty much everything will differ for different clients, I don't think there is a solution to this. Better said, I don't think there is a problem.

> points and the size of a chunk sent.

Those things are all implementation specific IMO, they are not protocol issues.

-acbegen

---

From: Kathy McEwen <[email-masked]>
Date: Wed, 6 Oct 2010 15:47:50 -0700

Content does not have to be pushed from broadcaster to a source server and then to a CDN to make it out to users devices.  We are working directly with very large national broadcasters in north america and Europe who want to push multicast broadcast real time event content on to the web directly from their sites to users much like they do with content pushed to cable and satellite distribution networks. 

.../Kathy 

Sent from my mobile

On Oct 6, 2010, at 3:40 PM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

> _______________________________________________
> httpstreaming mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/httpstreaming

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 6 Oct 2010 18:50:31 -0400

> Sure, http streaming or streaming over another protocol will always be delayed. The content generation, pushing it to the source servers and CDN and then getting them to the clients plus the playou…

Are you talking about start times, or latency behind real time ? If it takes you a minimum of 20 seconds to start your video, you might as well not
bother from a business standpoint, IMHO.

Even small differences in video start times are viewed as a powerful competitive advantage in this
business, and so there is going to be a strong push to shorten start times.

Regards
Marshall

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 6 Oct 2010 16:35:16 -0700

Sure but preparing that content for multicast does not happen right away. If you want adaptive streaming style delivery over the web, you will incur delays. And there is wrong with that. 

However, if you are saying they first prepare the content for web delivery and then push it to iptv or cable networks, the delay diff will be less between them, although relative delay wrt OTA will not change much. 

-acbegen

----- Original Message -----
From: Kathy McEwen <[email-masked]>
To: Ali C. Begen (abegen)
Cc: Roni Even <[email-masked]>; David A. Bryan <[email-masked]>; Qin Wu <[email-masked]>; [email-masked] <[email-masked]>
Sent: Wed Oct 06 15:47:50 2010
Subject: Re: [httpstreaming] Current Status and Our Goal

.../Kathy 

Sent from my mobile

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 6 Oct 2010 16:38:56 -0700

I was referring to latecy wrt real time. That is what Roni was talking about from what I can tell. 

As for the startup delay, nobody is saying the opposite. But tricks to make it faster are secret sauce to each implementation. And in unicast (as opposed to multicast), there more available tools at our disposal. 

-acbegen

----- Original Message -----
From: Marshall Eubanks <[email-masked]>
To: Ali C. Begen (abegen)
Cc: Roni Even <[email-masked]>; David A. Bryan <[email-masked]>; Qin Wu <[email-masked]>; [email-masked] <[email-masked]>
Sent: Wed Oct 06 15:50:31 2010
Subject: Re: [httpstreaming] Current Status and Our Goal

Regards
Marshall

---

From: Kathy McEwen <[email-masked]>
Date: Wed, 6 Oct 2010 16:47:58 -0700

There are ways to reduce and eliminate the delays to set up the multicast as well.  Adaptive streaming over the web does not preclude improvements to multicast efficiencies.  Rather, a co operative implementation of adaptive streaming and highly efficient multicasting is perhaps the needed secret sauce... To be made not so secret thru open industry standardization.

.../Kathy

Sent from my mobile

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 6 Oct 2010 17:28:02 -0700

> > Sure but preparing that content for multicast does not happen right away. If you want adaptive streaming style delivery
> over the web, you will incur delays. And there is wrong with that.

Sorry for the missing word. I meant there is *nothing* wrong with that.

> From: Kathy McEwen [mailto:[email-masked]]
> Sent: Thursday, October 07, 2010 7:48 AM
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
> There are ways to reduce and eliminate the delays to set up the multicast as well.  Adaptive streaming over the web does not
> preclude improvements to multicast efficiencies.  Rather, a co operative implementation of adaptive streaming and highly
> efficient multicasting is perhaps the needed secret sauce... To be made not so secret thru open industry standardization.

Oh well, I don't disagree with the above except the fact that some things are meant to stay as secret sauce. Furthermore, viewers are becoming more and more non-live content consumers even for the live events (for different reasons).

-acbegen

---

From: Kathy McEwen <[email-masked]>
Date: Wed, 6 Oct 2010 17:44:47 -0700

There is a problem with delay over the web if a service provider wants to provide a service with the absolute minimal delays giving consumers of broadcast tv an experience they have come to expect on delivery setup times.  Perhaps physics will preclude us from ever being as fast as delivering all content down a pipe to consumers homes...we may still find ways to be supremely better than 20 seconds or even 1 to 2 seconds. 

Sent from my mobile

---

From: Colin Perkins <[email-masked]>
Date: Thu, 7 Oct 2010 12:16:58 +0100

On 6 Oct 2010, at 22:56, Roni Even wrote:
> My view is that we are trying to address the transport of media in  
> HTTP both pre-recorded and live. The major issues I see are
>
> 1. Address the issue of allowing both push and pull models  
> (addressing the use cases and concerns from Qin draft)
> 2. Address the startup issue, we have worked in AVT on fast channel/ 
> content change and I think this is relevant also in this case.

There are clearly some issues to consider here. What seems to be  
missing from the discussion to me though, is some identification of  
the concrete problems. What protocol pieces do we need, but not have?  
What protocols are problematic, and need enhancement? Is there  
protocol work to do in IETF, or should we be documenting best current  
practices for using the existing protocols and/or relying on other  
bodies to fill the gaps?

The draft-wu-http-streaming-optimization-ps is a good start at such an  
analysis, but doesn't go deep enough to let us decide what work IETF  
should do.

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Fri, 08 Oct 2010 15:21:59 +0800

> understanding of what is the charter of the work. 

[Qin]: Good point, we do have some use cases which hasn't been taken out from 
HTTP Streaming Problem Statement draft (http://www.ietf.org/id/draft-wu-http-streaming-optimization-ps-02.txt).
Four typical use cases in my mind would be:
case 1: Live Streaming Media broadcast
case 2: RTP to HTTP Gateway, which is possible case to address multicast support.
case 3: "Multi-Screen" Service Delivery
case 4:  Heterogeneous Handover
Hope it helps get a better understanding what the scenarios may may look like. If anybody would like to contribute to use case document
or provide more input, that will be great.

---

From: Qin Wu <[email-masked]>
Date: Fri, 08 Oct 2010 15:59:52 +0800

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

[Qin]: Good input, that's one issue we are addressing in the problem statement draft, i.e., Lacking Streaming Monitoring and Feedback Support. I think the chunk hint will be also very useful in case chunks loss or any exception as regarding to sever and network condition happens. Another advantage is with such chunk hints, we may not rely on manifest and playlist to fetch the chunks one by one. The problem is do we have approach to provide such hint to the server/cache?

---

From: Qin Wu <[email-masked]>
Date: Fri, 08 Oct 2010 16:16:25 +0800

[Qin] I think Synchronization between the server and the client is one issue we may look at. Since the server has buffer for encoding, the client has a buffer for playout, we definitely need one streaming media synchronization mechanism which may help reduce delay.

[Qin] I think two synchronizaton points are refering to the server and client rather than two clients as viewers.

-acbegen

---

From: Lars Eggert <[email-masked]>
Date: Fri, 8 Oct 2010 11:16:35 +0300

> analysis, but doesn't go deep enough to let us decide what work IETF  

+1 

The key question really is "what do you think the IETF needs to do?"

Lars

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 9 Oct 2010 09:43:40 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Lars Eggert
> Sent: Friday, October 08, 2010 4:17 PM
> To: Colin Perkins

I imagine the only work the IETF should do (if we decide to) is the transport and HTTP-layer optimization for better streaming performance.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 9 Oct 2010 09:46:14 -0700

> From: Qin Wu [mailto:[email-masked]]
> Sent: Friday, October 08, 2010 4:16 PM
> To: Ali C. Begen (abegen); Roni Even; David A. Bryan
> Synchronization among the viewers you mean? That could be a concern but seriously, since client implementations will
> differ, network capacities will differ, i.e., pretty much everything will differ for different clients, I don't think there is a
> solution to this. Better said, I don't think there is a problem.
> 
> [Qin] I think Synchronization between the server and the client is one issue we may look at. Since the server has buffer for
> encoding, the client has a buffer for playout, we definitely need one streaming media synchronization mechanism which may
> help reduce delay.

Sorry, I don’t get this. Server or someone else advertises what is available to the client and client fetches whatever it wants (and is available). Why is there a need for synchronization here?

-acbegen

---

From: Mark Watson <[email-masked]>
Date: Sat, 9 Oct 2010 16:13:53 -0700

All,

I would like to add my support to the comments below. Specifically, I think if the IETF considers work in this area it should focus on the HTTP and TCP protocols. Any such work may not be specific to HTTP-streaming (i.e. enhancements that are at first motivated by HTTP Streaming may have broader applicability, and this should be carefully considered).

In the draft I do not see a clear or correct identification of the problems. For example in the introduction the following are stated as issues:

   - Client polling for each new data in chunks using HTTP requests is
   not efficient to deliver high-quality video content across the
   Internet

MW: Several companies, including my employer, are successfully operating large scale HTTP streaming systems that do efficiently deliver high-quality video content across the Internet, so reality seems to refute this statement.

   - Segmentation capability requires over-utilizing CPU and bandwidth
   resources, which may not be a desirable and effective way to improve
   the quality of streaming media delivery

MW: It is not clear that segmentation per se is CPU-intensive or has any non-negligable effect on bandwidth usage.

   - Lack of QoS guarantee on the packet switching based Internet , the
   quality of Internet media streaming may significant degrade due to
   rising usage

MW: An alternative view is that where quality is degraded due to congestion this is due to lack of bandwidth, rather than a lack of QoS guarantees. Adaptive HTTP streaming systems adjust the video quality to the available bandwidth in order to avoid rebuffering events. It is the available bandwidth that needs to be improved to improve quality.

   - Experience burstiness or other dynamics changes due to bandwidth
   fluctuations and heterogeneous handover.

MW: We have found that adaptive HTTP streaming algorithms are well able to cope with bandwidth fluctuations.

   - Impossible to fast-forward through any part of a streaming
   contents until it is stored on the user's device

MW: This is simply not correct, since there are hundreds of examples of devices which support trick-play using HTTP streaming techniques without storing the whole content on the users device.

A first step in considering what, if any, work should be done here might be to contact those organizations which are standardizing the higher layers of HTTP streaming systems (e.g. manifest and file formats) and ask whether there are deficiencies they see in IETF protocols that could be usefully addressed by the IETF. What I think we should avoid in the IETF is duplicating the work of these other bodies.

Best,

Mark Watson

Netflix Inc.

On Oct 10, 2010, at 12:43 AM, Ali C. Begen (abegen) wrote:

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Lars Eggert
Sent: Friday, October 08, 2010 4:17 PM
To: Colin Perkins
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [httpstreaming] Current Status and Our Goal

+1

-acbegen

Lars
_______________________________________________
httpstreaming mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/httpstreaming

---

From: Ye-Kui Wang <[email-masked]>
Date: Sat, 09 Oct 2010 19:28:10 -0400

> I imagine the only work the IETF should do (if we decide to) 
> is the transport and HTTP-layer optimization for better 
> streaming performance.

I second, as one who has been heavily involved HTTP streaming
standardization in 3GPP, MPEG and OIPF.

BR, YK 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ali C. 
> Begen (abegen)
> Sent: Saturday, October 09, 2010 12:44 PM
> To: Lars Eggert; Colin Perkins
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Lars Eggert
> > > protocol work to do in IETF, or should we be documenting best 
> > > current practices for using the existing protocols and/or 
> relying on 
> > > other bodies to fill the gaps?
> > >
> > > The draft-wu-http-streaming-optimization-ps is a good 
> start at such 
> > > an analysis, but doesn't go deep enough to let us decide 
> what work 
> > > IETF should do.
> > 
> > +1
> > 
> I imagine the only work the IETF should do (if we decide to) 
> is the transport and HTTP-layer optimization for better 
> streaming performance.
> 
> -acbegen
>  
> > Lars

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 9 Oct 2010 17:04:15 -0700

> From: Ye-Kui Wang [mailto:[email-masked]]
> Sent: Sunday, October 10, 2010 7:28 AM
> To: Ali C. Begen (abegen); 'Lars Eggert'; 'Colin Perkins'

Actually for one, I don’t like the word "optimization" myself which is not very meaningful here. So, I should rather say "any marginal improvement is welcome".

-acbegen

---

From: Wenbo Zhu <[email-masked]>
Date: Sun, 10 Oct 2010 00:27:15 -0700

> I imagine the only work the IETF should do (if we decide to) is the transport and HTTP-layer optimization for better streaming performance.
Or more importantly to standardize existing or proposed optimizations
for improved interoperability, with which intermediaries will be able
to offer direct support for streaming traffic, and different client
platforms will also be able to improve end-user experience
independently of vendor or media-protocol specific solutions.

- Wenbo

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 10 Oct 2010 00:32:02 -0700

> From: Wenbo Zhu [mailto:[email-masked]]
> Sent: Sunday, October 10, 2010 3:27 PM
> Cc: Lars Eggert; Colin Perkins; [email-masked]

Wanna give a specific example for "intermediaries"? I think you are referring to something besides the http caches.

> independently of vendor or media-protocol specific solutions.

Sure but is not that all client implementation, which is mostly left for product differentiation?

-acbegen

---

From: Wenbo Zhu <[email-masked]>
Date: Sun, 10 Oct 2010 00:39:00 -0700

> Wanna give a specific example for "intermediaries"? I think you are referring to something besides the http caches.
proxies.

> Sure but is not that all client implementation, which is mostly left for product differentiation?
I am interested to find out whether existing implementations (that
have successfully deployed HTTP-based streaming over internet) expose
streaming resource via open protocols or API's?

- Wenbo

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 10 Oct 2010 00:45:49 -0700

> > Wanna give a specific example for "intermediaries"? I think you are referring to something besides the http caches.

What should a proxy support for streaming?
 
> streaming resource via open protocols or API's?

There are source codes floating around (with different licenses of course). Have you looked at OSMF and OVP?
http://openvideoplayer.sourceforge.net/
http://opensource.adobe.com/wiki/display/osmf/Open+Source+Media+Framework 

-acbegen

---

From: Wenbo Zhu <[email-masked]>
Date: Sun, 10 Oct 2010 02:17:12 -0700

> What should a proxy support for streaming?
Proxies don't know anything about streaming, and they only understand
HTTP. If the goal is to optimize the transport, then clearly defined
protocol semantics would be necessary for proxies to distinguish
streaming traffic from regular HTTP traffic.

> http://opensource.adobe.com/wiki/display/osmf/Open+Source+Media+Framework
Thanks for the info.

- Wenbo

---

From: Mark Watson <[email-masked]>
Date: Sun, 10 Oct 2010 02:38:00 -0700

> streaming traffic from regular HTTP traffic.

One of the great advantages of HTTP streaming as a technique is that the infrastructure is exactly common with that of the web. Requiring proxies to distinguish between "streaming" and "regular" traffic would break that.

Instead, if there are different behaviors which are considered advantageous for streaming, then these should be considered as general-purpose HTTP enhancements.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 10 Oct 2010 03:09:06 -0700

But then that is not a proxy anymore. You probably do not wanna replace all those proxies or introduce new ones with heavier tasks.  

-acbegen

----- Original Message -----
From: Wenbo Zhu [mailto:[email-masked]]
Sent: Sunday, October 10, 2010 02:17 AM
To: Ali C. Begen (abegen)
Cc: Lars Eggert <[email-masked]>; Colin Perkins <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [httpstreaming] Current Status and Our Goal

Thanks for the info.

- Wenbo

---

From: Wenbo Zhu <[email-masked]>
Date: Sun, 10 Oct 2010 20:59:48 -0700

> One of the great advantages of HTTP streaming as a technique is that the infrastructure is exactly common with that of the web. Requiring proxies to distinguish between "streaming" and "regular" tr…
Agreed. I could have worded this differently.

> Instead, if there are different behaviors which are considered advantageous for streaming, then these should be considered as general-purpose HTTP enhancements.
There is no need to enhance HTTP! It's about the ability to advise
streaming capabilities so that proxies that do choose to understand
streaming will be able to optimize and honor the streaming behaviors
that are specified on top of HTTP.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 11 Oct 2010 10:19:22 +0300

Hi,

> independently of vendor or media-protocol specific solutions.

so this discussion goes into the right direction. For a chartering discussion, however, we'd want to see arguments for which specific protocols the IETF (rather than, say, the W3C) should extend in which specific way, to address which specific deficiencies. (Then we can discuss whether the complexity is worth the improvement.)

Lars

---

From: Qin Wu <[email-masked]>
Date: Mon, 11 Oct 2010 16:56:41 +0800

How about  we say:
To provide better transport to satisfy real time streaming requirements.
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Ye-Kui Wang" <[email-masked]>; "Lars Eggert" <[email-masked]>; "Colin Perkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, October 10, 2010 8:04 AM
Subject: Re: [httpstreaming] Current Status and Our Goal

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Mon, 11 Oct 2010 17:14:40 +0800

Hi,:
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Roni Even" <[email-masked]>; "David A. Bryan" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, October 10, 2010 12:46 AM
Subject: RE: [httpstreaming] Current Status and Our Goal

[Qin]: We may look at two different  use cases: push model and pull model
In the pull model, you are right. The client  control the timing of fetching the chunks by driving the HTTP request. It only request it needs and can handle. However  client based pull is characterized
as polling for new data each time and is not efficient way to deliver the real time streaming contents.
In the push model, the client does not know when the conents is available at the server. For the client will not send request for each chunks. the client clock is easy to asynchronize with encoder clock.

---

From: Qin Wu <[email-masked]>
Date: Mon, 11 Oct 2010 19:50:27 +0800

Hi,
This is what we had discussed  in the DISPATCH mailing list before we move to this discuss list.
If you look at the description of discuss list, "
offers more efficient transport 
and better network capability for real time streaming media
and allows interoperability with other streaming techniques and existing Progressive dowloaded based
HTTP streaming implementation.
"
you will see we are on the same page.
Therefore one important goal discussed in the draft aims at developing interoperable solution to 
provide better transport to satisfy the real time streaming QOE requirement. Especially serveral
chanllenges/problems we explored in the draft listed below.

Regards!
-Qin
  ----- Original Message ----- 
  From: Mark Watson 
  To: Ali C. Begen (abegen) 
  Cc: [email-masked] ; Colin Perkins 
  Sent: Sunday, October 10, 2010 7:13 AM
  Subject: Re: [httpstreaming] Current Status and Our Goal

  All,

  In the draft I do not see a clear or correct identification of the problems. For example in the introduction the following are stated as issues:
   - Client polling for each new data in chunks using HTTP requests is
   not efficient to deliver high-quality video content across the
   InternetMW: Several companies, including my employer, are successfully operating large scale HTTP streaming systems that do efficiently deliver high-quality video content across the Internet, so reality seems to refute this statement.[Qin]: Not sure they can provide the TV experience for all the connected devices like smartphones, PCs and tablets. Also not sure they can provide the same quality of experence for all the all the connected devices. As we discussed in this thread, a minimum of 20 seconds to start your video often frustrated users to keep on watching and provide very limited user experience.On the other hand, I think we should bear in mind HTTP is formerly designed for browsing webpage, transport static contents like HTML page, plugin, picture, when we are going to use HTTP to deliver real time streaming contents, we can not expect to get higher user experience. Therefore the current streaming schemes can only offer a better experience over slower connections.   - Segmentation capability requires over-utilizing CPU and bandwidth
   resources, which may not be a desirable and effective way to improve
   the quality of streaming media deliveryMW: It is not clear that segmentation per se is CPU-intensive or has any non-negligable effect on bandwidth usage.[Qin]: Since HTTP streaming server is the combination of streaming server and regular web server, I think the answer is both.   - Lack of QoS guarantee on the packet switching based Internet , the
   quality of Internet media streaming may significant degrade due to
   rising usageMW: An alternative view is that where quality is degraded due to congestion this is due to lack of bandwidth, rather than a lack of QoS guarantees. Adaptive HTTP streaming systems adjust the video quality to the available bandwidth in order to avoid rebuffering events. It is the available bandwidth that needs to be improved to improve quality.[Qin]: What I emphasize here is with growing popularity of HTTP streaming traffic, when thousands or millions of people are accessing the same media contents, the big problem we are facing is serious high concurrence access issue. The user experience will be greatly affected even you have enough available bandwidth. So this is not pure bandwidth issue.   - Experience burstiness or other dynamics changes due to bandwidth
   fluctuations and heterogeneous handover.MW: We have found that adaptive HTTP streaming algorithms are well able to cope with bandwidth fluctuations. [Qin]: I don't doubt that adaptive HTTP streaming algorithms can cope with bandwidth fluctation. But I hope we can do better.e.g., adaptive HTTP streaming algorithms only support delivery of multiple streams of the same content with varying quality levels for different bandwidth or devices. Howeve how the server in push model or client in pull model can quick response to the bitrate changes is a problem we may look at,especially when switching beween streams occurs very frequently.   - Impossible to fast-forward through any part of a streaming
   contents until it is stored on the user's deviceMW: This is simply not correct, since there are hundreds of examples of devices which support trick-play using HTTP streaming techniques without storing the whole content on the users device.[Qin]: Fast forward capabilty is not the most important feature we are looking for. However I am hard to believe existing HTTP streaming techniques can provide the same degree of playbackcontrol that DVD player can provides or RTSP protocol provides. E.g., In the adaptive HTTP streaming algorithms, the trick play is limited to pause/resume/stop by driving the HTTP request. If the contents hasn't been dowloaded  and the consume want fast forward, the HTTP client needs to issue another new HTTP request to fetch the contents which willcause unacceptable latency to the consumer.A first step in considering what, if any, work should be done here might be to contact those organizations which are standardizing the higher layers of HTTP streaming systems (e.g. manifest and file formats) and ask whether there are deficiencies they see in IETF protocols that could be usefully addressed by the IETF. What I think we should avoid in the IETF is duplicating the work of these other bodies.Best,Mark WatsonNetflix Inc.

      -----Original Message-----

      To: Colin Perkins

        bodies to fill the gaps?

        should do.

      +1

    -acbegen

      Lars

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

---

From: Mark Watson <[email-masked]>
Date: Mon, 11 Oct 2010 09:50:35 -0700

Some comments online ...

Sent from my iPhone

On Oct 11, 2010, at 7:50 PM, "Qin Wu" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards!
-Qin
----- Original Message -----
From: Mark Watson<mailto:[email-masked]>
To: Ali C. Begen (abegen)<mailto:[email-masked]>
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> ; Colin Perkins<mailto:[email-masked]>
Sent: Sunday, October 10, 2010 7:13 AM
Subject: Re: [httpstreaming] Current Status and Our Goal

All,

[Qin]: Not sure they can provide the TV experience for all the connected devices like smartphones, PCs and tablets. Also not sure they can provide the same quality of experence for all the all the connected devices. As we discussed in this thread, a minimum of 20 seconds to start your video often frustrated users to keep on watching and provide very limited user experience.

Can you be more explicit about the problems that you see? I'm not sure where the 20s figure comes from. I do not see any problem in supporting startup times comparable to TV channel change with adaptive HTTP streaming.

I am not saying there is no room for improvement in the various deployed systems, but I do not see major technical impediments to efficient delivery of high quality video using HTTP Streaming.

On the other hand, I think we should bear in mind HTTP is formerly designed for browsing webpage, transport static contents like HTML page, plugin, picture, when we are going to use HTTP to deliver real time streaming contents, we can not expect to get higher user experience. Therefore the current streaming schemes can only offer a better experience over slower connections.

[Qin]: Since HTTP streaming server is the combination of streaming server and regular web server, I think the answer is both.

[MW] what do you mean by' http streaming server' ?

[Qin]: What I emphasize here is with growing popularity of HTTP streaming traffic, when thousands or millions of people are accessing the same media contents, the big problem we are facing is serious high concurrence access issue. The user experience will be greatly affected even you have enough available bandwidth. So this is not pure bandwidth issue.

[MW] maybe we mean different things by 'available bandwidth'. Do you think it is a server scalability problem, or a network problem ?

[Qin]: I don't doubt that adaptive HTTP streaming algorithms can cope with bandwidth fluctation. But I hope we can do better.e.g., adaptive HTTP streaming algorithms only support delivery of multiple streams of the same content with varying quality levels for different bandwidth or devices. Howeve how the server in push model or client in pull model can quick response to the bitrate changes is a problem we may look at,especially when switching beween streams occurs very frequently.

[MW] Yes, but not a problem for the IETF, I think.

[Qin]: Fast forward capabilty is not the most important feature we are looking for. However I am hard to believe existing HTTP streaming techniques can provide the same degree of playbackcontrol that DVD player can provides or RTSP protocol provides. E.g., In the adaptive HTTP streaming algorithms, the trick play is limited to pause/resume/stop by driving the HTTP request. If the contents hasn't been dowloaded  and the consume want fast forward, the HTTP client needs to issue another new HTTP request to fetch the contents which willcause unacceptable latency to the consumer.

[MW] Again, the experience of millions of existing customers refutes what you claim. Why do you think it is necessarily so slow to issue a new HTTP request for a different part of the content?

Best,

Mark Watson

Netflix Inc.

-----Original Message-----
From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Lars Eggert
Sent: Friday, October 08, 2010 4:17 PM
To: Colin Perkins
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [httpstreaming] Current Status and Our Goal

+1

-acbegen

Lars
_______________________________________________
httpstreaming mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/httpstreaming

________________________________

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 11 Oct 2010 17:09:30 -0700

> Sent: Monday, October 11, 2010 5:15 AM
> Sorry, I don’t get this. Server or someone else advertises what is available to the client and client fetches whatever it wants
> (and is available). Why is there a need for synchronization here?
> 
> In the pull model, you are right. The client  control the timing of fetching the chunks by driving the HTTP request. It only
> request it needs and can handle. However  client based pull is characterized

By polling I suppose you mean sending HTTP requests. Well, that is pretty much implied by using HTTP, which is a request-response protocol and this makes HTTP as stateless as possible. And IMO sending individual requests offer more advantages than disadvantages.

> In the push model, the client does not know when the conents is available at the server. For the client will not send request
> for each chunks. the client clock is easy to asynchronize with encoder clock.

Well the server can push the content (in a push model) but it still is dependent on the client implementation to determine what to do with that content. One implementation, if it wants, can start playing it 10 hours later for all we care. I still don't get what you are trying to do here.

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Thu, 14 Oct 2010 14:21:08 +0800

Hi,
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Roni Even" <[email-masked]>; "David A. Bryan" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 12, 2010 8:09 AM
Subject: RE: [httpstreaming] Current Status and Our Goal

[Qin]: Suppose ten chunks are available at the server, the client in pull model MUST send ten requests to fetch all the chunks and server should answer with ten response with each chunk.
however in the push model, I think the client only need to initiate one request and then the server control ten chunks delivery and push ten chunks to the client one by one.
 Isn't the push model more efficient than pull model from transport perspective?

[Qin]: In the push model, the server didn't know the client capability to consume streaming data, i.e., the server didn't know how fast the client process live streaming. If the encoding rate at the server is faster than comsuing rate at the client, the buffer will overflow. If the encoding rate at the server is slower than comsuing rate at the client, the buffer will underflow.

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Thu, 14 Oct 2010 14:41:39 +0800

Hi,
  ----- Original Message ----- 
  From: Mark Watson 
  To: Qin Wu 
  Cc: Ali C. Begen (abegen) ; [email-masked] ; Colin Perkins 
  Sent: Tuesday, October 12, 2010 12:50 AM
  Subject: Re: [httpstreaming] Current Status and Our Goal

  Some comments online ...

  Sent from my iPhone

  On Oct 11, 2010, at 7:50 PM, "Qin Wu" <[email-masked]> wrote:

    Hi,

    Regards!
    -Qin
      ----- Original Message ----- 
      From: Mark Watson 
      To: Ali C. Begen (abegen) 
      Cc: [email-masked] ; Colin Perkins 
      Sent: Sunday, October 10, 2010 7:13 AM
      Subject: Re: [httpstreaming] Current Status and Our Goal

      All, 

      In the draft I do not see a clear or correct identification of the problems. For example in the introduction the following are stated as issues:
   - Client polling for each new data in chunks using HTTP requests is
   not efficient to deliver high-quality video content across the
   InternetMW: Several companies, including my employer, are successfully operating large scale HTTP streaming systems that do efficiently deliver high-quality video content across the Internet, so reality seems to refute this statement.[Qin]: Not sure they can provide the TV experience for all the connected devices like smartphones, PCs and tablets. Also not sure they can provide the same quality of experence for all the all the connected devices. As we discussed in this thread, a minimum of 20 seconds to start your video often frustrated users to keep on watching and provide very limited user experience.Can you be more explicit about the problems that you see? I'm not sure where the 20s figure comes from. I do not see any problem in supporting startup times comparable to TV channel change with adaptive HTTP streaming.

  [Qin]:Not only starup latency but also delay w.r.t. real time streaming. I think you negect it becos You didn't get into the discussion list. 

On the other hand, I think we should bear in mind HTTP is formerly designed for browsing webpage, transport static contents like HTML page, plugin, picture, when we are going to use HTTP to deliver real time streaming contents, we can not expect to get higher user experience. Therefore the current streaming schemes can only offer a better experience over slower connections.   - Segmentation capability requires over-utilizing CPU and bandwidth
   resources, which may not be a desirable and effective way to improve
   the quality of streaming media deliveryMW: It is not clear that segmentation per se is CPU-intensive or has any non-negligable effect on bandwidth usage.[Qin]: Since HTTP streaming server is the combination of streaming server and regular web server, I think the answer is both.

  [Qin]: With streaming capability and functionality to respond to HTTP connection.

   - Lack of QoS guarantee on the packet switching based Internet , the
   quality of Internet media streaming may significant degrade due to
   rising usageMW: An alternative view is that where quality is degraded due to congestion this is due to lack of bandwidth, rather than a lack of QoS guarantees. Adaptive HTTP streaming systems adjust the video quality to the available bandwidth in order to avoid rebuffering events. It is the available bandwidth that needs to be improved to improve quality.[Qin]: What I emphasize here is with growing popularity of HTTP streaming traffic, when thousands or millions of people are accessing the same media contents, the big problem we are facing is serious high concurrence access issue. The user experience will be greatly affected even you have enough available bandwidth. So this is not pure bandwidth issue.

  [Qin]: please read http://www.ietf.org/mail-archive/web/httpstreaming/current/msg00011.html

   - Experience burstiness or other dynamics changes due to bandwidth
   fluctuations and heterogeneous handover.MW: We have found that adaptive HTTP streaming algorithms are well able to cope with bandwidth fluctuations. [Qin]: I don't doubt that adaptive HTTP streaming algorithms can cope with bandwidth fluctation. But I hope we can do better.e.g., adaptive HTTP streaming algorithms only support delivery of multiple streams of the same content with varying quality levels for different bandwidth or devices. Howeve how the server in push model or client in pull model can quick response to the bitrate changes is a problem we may look at,especially when switching beween streams occurs very frequently.

  [Qin]: I didn't get what you said. adaptive HTTP streaming algorithms is characterized as  client initiated pull model. We are discussing push model or how to use pull model with push model.We are talking about different model. There are plenty room for IETF to do for this.

   - Impossible to fast-forward through any part of a streaming
   contents until it is stored on the user's deviceMW: This is simply not correct, since there are hundreds of examples of devices which support trick-play using HTTP streaming techniques without storing the whole content on the users device.[Qin]: Fast forward capabilty is not the most important feature we are looking for. However I am hard to believe existing HTTP streaming techniques can provide the same degree of playbackcontrol that DVD player can provides or RTSP protocol provides. E.g., In the adaptive HTTP streaming algorithms, the trick play is limited to pause/resume/stop by driving the HTTP request. If the contents hasn't been dowloaded  and the consume want fast forward, the HTTP client needs to issue another new HTTP request to fetch the contents which willcause unacceptable latency to the consumer.[MW] Again, the experience of millions of existing customers refutes what you claim. Why do you think it is necessarily so slow to issue a new HTTP request for a different part of the content?

  [Qin]: You didn't see the reaon behind this, becos the existing customers has no choice when they view live streaming, what they can get is close to live experience rather than real time user experience. Operatoer do nothing for their network to make http streaming more controllable and managable. Therefore more and more consumer tend to choose non-live content. that's why we see more and more non-live content consumers rather than live contents consumers. 

A first step in considering what, if any, work should be done here might be to contact those organizations which are standardizing the higher layers of HTTP streaming systems (e.g. manifest and file formats) and ask whether there are deficiencies they see in IETF protocols that could be usefully addressed by the IETF. What I think we should avoid in the IETF is duplicating the work of these other bodies.Best,Mark WatsonNetflix Inc.

          -----Original Message-----

          To: Colin Perkins

            bodies to fill the gaps?

            should do.

          +1

        -acbegen

          Lars

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

---

From: Qin Wu <[email-masked]>
Date: Thu, 14 Oct 2010 14:48:15 +0800

Hi,
----- Original Message ----- 
From: "luzhihui" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Roni Even" <[email-masked]>; "'David A. Bryan'" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 13, 2010 12:54 AM
Subject: Re: Re: [httpstreaming] Current Status and Our Goal

> 
> 
> ======= 2010-10-08 03:23:04 您在来信中写道：=======
> 
> [ZhiHui] Qin, we know http is web content-oriented at begining, so we have Real Time Streaming Protocol (RTSP) and MMS (Microsoft Media Server protocol) 
> oriented for streaming,RTSP and MMS are based on RTP, they are popular for streaming content delivery. But now because of simplicity of HTTP, HTTP come 
> again for streaming.  We know this is HTTP "Second Spring"
> So Flash player now become more popular than Real player and Media Player.  But we know RTP protocol is very friendly to streaming content chunk.
> So, If we design  RTP to HTTP Gateway, we should consider how to utilize the existing advantages of RTP over TCP.

[Qin]: I am not sure we need to build such Gateway. The motivation to look deep into it is how to introduce multicast support for HTTP streaming.
One existing protocol we may look at is RTMP, one of features in RTMP is multicast support.

> = = = = = = = = = = = = = = = = = = = =
> 
> 
> 
> 　　　　　ZhiHui
>    
> Tel：021-65107607，65643187
> Fax：021-65647894
> Mob：13818168919
> 　　　　　　　　　　2010-10-12
>

---

From: Mark Watson <[email-masked]>
Date: Thu, 14 Oct 2010 09:26:01 -0700

On Oct 14, 2010, at 2:41 PM, Qin Wu wrote:

Hi,
----- Original Message -----
From: Mark Watson<mailto:[email-masked]>
To: Qin Wu<mailto:[email-masked]>
Cc: Ali C. Begen (abegen)<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; Colin Perkins<mailto:[email-masked]>
Sent: Tuesday, October 12, 2010 12:50 AM
Subject: Re: [httpstreaming] Current Status and Our Goal

Some comments online ...

Sent from my iPhone

Hi,

Regards!
-Qin
----- Original Message -----
From: Mark Watson<mailto:[email-masked]>
To: Ali C. Begen (abegen)<mailto:[email-masked]>
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> ; Colin Perkins<mailto:[email-masked]>
Sent: Sunday, October 10, 2010 7:13 AM
Subject: Re: [httpstreaming] Current Status and Our Goal

All,

[MW] I'm not sure what one of those is. It sounds like it is not a regular web server. I think it's an essential feature of modern HTTP streaming that it works with regular web infrastructure.

[MW] Still not sure what you're referring to other than available bandwidth. The thread mentions multicast - do you think there remains work to deliver HTTP objects over multicast given the work in RMT over the years ?

[MW] Sorry, I don't understand what the "push" model has to do with HTTP Streaming. Are you talking about servers which are not regular HTTP servers ? I think this is not what people usually mean when they say "HTTP streaming" - you should rename the work if that is the case.

[MW] Well, I'm not sure I understand the point. But still the statement in the draft is not true.

...Mark

Best,

Mark Watson

Netflix Inc.

-----Original Message-----
From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Lars Eggert
Sent: Friday, October 08, 2010 4:17 PM
To: Colin Perkins
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [httpstreaming] Current Status and Our Goal

+1

-acbegen

Lars

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 14 Oct 2010 15:49:59 -0700

> Sent: Thursday, October 14, 2010 2:21 AM
> By polling I suppose you mean sending HTTP requests. Well, that is pretty much implied by using HTTP, which is a request-
> response protocol and this makes HTTP as stateless as possible. And IMO sending individual requests offer more advantages
> than disadvantages.
> 
> [Qin]: Suppose ten chunks are available at the server, the client in pull model MUST send ten requests to fetch all the chunks
> and server should answer with ten response with each chunk.
> however in the push model, I think the client only need to initiate one request and then the server control ten chunks delivery
> and push ten chunks to the client one by one.

Depends. Just because in the push model there are less request messages, it does not mean it is more efficient. That would be a bad definition for efficiency. The pull model brings many advantages that the push model cannot offer (at the same flexibility). I am not saying one is better than the other, but your scope for determining efficiency is rather limited.
 
> Well the server can push the content (in a push model) but it still is dependent on the client implementation to determine
> what to do with that content. One implementation, if it wants, can start playing it 10 hours later for all we care. I still don't
> get what you are trying to do here.
> 
> [Qin]: In the push model, the server didn't know the client capability to consume streaming data, i.e., the server didn't know
> how fast the client process live streaming. If the encoding rate at the server is faster than comsuing rate at the client, the
> buffer will overflow. If the encoding rate at the server is slower than comsuing rate at the client, the buffer will underflow.

For both on-demand and live streaming, the encoding rate is supposed to be equal to consumption rate (which sounds to me as the rate the decoder is consuming). What you are referring to as buffer overflow or underflow is related to streaming or transmission rate. On the long-term average, all these need to be equal anyway. But, I will just repeat myself. Neither has anything to do with clock synchronization between the server and client. The client can choose the buffer duration and the actual playback time.

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Fri, 15 Oct 2010 08:57:30 +0800

Hi,
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Roni Even" <[email-masked]>; "David A. Bryan" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 15, 2010 6:49 AM
Subject: RE: [httpstreaming] Current Status and Our Goal

[Qin]: Okay. But If you look at websocket protocol as push model, probably you will find they can be used accelerate browser and improve efficiency.
 
> buffer will overflow. If the encoding rate at the server is slower than comsuing rate at the client, the buffer will underflow.

For both on-demand and live streaming, the encoding rate is supposed to be equal to consumption rate (which sounds to me as the rate the decoder is consuming). What you are referring to as buffer overflow or underflow is related to streaming or transmission rate. On the long-term average, all these need to be equal anyway. 

[Qin]: But How, is there any way to do this? or they just wait for rebuffering and then recover by itself.

But, I will just repeat myself. Neither has anything to do with clock synchronization between the server and client. 

[Qin]: Okay.

The client can choose the buffer duration and the actual playback time.

[Qin]: Suppose the chunks is not ready in the playout buffer at the client, does it mean that the client just slow down playback speed and wait for subsequent chunks is arriving at the playback buffer and then client resume the normal
playback speed?

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 14 Oct 2010 18:11:12 -0700

> Sent: Thursday, October 14, 2010 8:58 PM
> > > > encoding, the client has a buffer for playout, we definitely need one streaming media synchronization mechanism
> which
> > > may
> > > > help reduce delay.
> > >
> Depends. Just because in the push model there are less request messages, it does not mean it is more efficient. That would
> be a bad definition for efficiency. The pull model brings many advantages that the push model cannot offer (at the same
> flexibility). I am not saying one is better than the other, but your scope for determining efficiency is rather limited.
> 

But, in http streaming scenario, the ratio of download/upload (from the client's perspective) is much larger than 1. BTW, if you keep your chunk duration relatively longer, the amount of requests that you will end up sending will be almost nil compared to what you will receive.
 
> For both on-demand and live streaming, the encoding rate is supposed to be equal to consumption rate (which sounds to me
> as the rate the decoder is consuming). What you are referring to as buffer overflow or underflow is related to streaming or
> transmission rate. On the long-term average, all these need to be equal anyway.
> 
> [Qin]: Suppose the chunks is not ready in the playout buffer at the client, does it mean that the client just slow down playback
> speed and wait for subsequent chunks is arriving at the playback buffer and then client resume the normal
> playback speed?

Sorry if "playback time" meant the duration of the playback. I rather meant the start time of the playback. So, if a client keeps a larger buffer hoping that it will avoid buffer underruns, this may delay the playback start time. Or, the client can start the playback quickly and build the buffer over time by requesting lower-bitrate chunks.

Whether it paces the presentation speed down or not in order to avoid buffer underruns is something up to the client. Most implementations I have seen simply switch to a lower-bitrate profile well before the buffer is fully drained. So, they don't experience buffer underruns and they don’t need to pace the video presentation speed down.

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Fri, 15 Oct 2010 09:50:41 +0800

Hi,
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Roni Even" <[email-masked]>; "David A. Bryan" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 15, 2010 9:11 AM
Subject: RE: [httpstreaming] Current Status and Our Goal

[Qin]: No, I just compare pull and push with the same chunk duration. 
 
> speed and wait for subsequent chunks is arriving at the playback buffer and then client resume the normal

Sorry if "playback time" meant the duration of the playback. I rather meant the start time of the playback. So, if a client keeps a larger buffer hoping that it will avoid buffer underruns, this may delay the playback start time. 

[Qin]: Right. So we need to choose approporiate buffer size to seek balance between buffer underflow and startup time delay. The buffer size can be changed at any time.

Or, the client can start the playback quickly and build the buffer over time by requesting lower-bitrate chunks.

[Qin]: I think the presumption is the server should prepare multiple streams of the same content with different bitrates. the server may have a big load if the content is live contents.

[Qin]: I don't doubt giving more control to client has its advantages. But I think giving some control to the server also has its advantage. e.g.,  you may not need to prepare multiple stream of the same content with different bitrate.
the server control the transmission rate based on the network condition and client requirements.

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Fri, 15 Oct 2010 11:22:21 +0800

I respect your opionion although I can't agree with you. I would like to hear what other people thinks. Thanks!
  ----- Original Message ----- 
  From: Mark Watson 
  To: Qin Wu 
  Cc: Ali C. Begen (abegen) ; [email-masked] ; Colin Perkins 
  Sent: Friday, October 15, 2010 12:26 AM
  Subject: Re: [httpstreaming] Current Status and Our Goal

    Hi,
      ----- Original Message -----
      From: Mark Watson
      To: Qin Wu
      Cc: Ali C. Begen (abegen) ; [email-masked] ; Colin Perkins
      Sent: Tuesday, October 12, 2010 12:50 AM
      Subject: Re: [httpstreaming] Current Status and Our Goal

      Some comments online ...

      Sent from my iPhone

        Hi,

        Regards!
        -Qin
          ----- Original Message -----
          From: Mark Watson

          All,

  ...Mark

              -----Original Message-----

              To: Colin Perkins

                bodies to fill the gaps?

                should do.

              +1

            -acbegen

              Lars

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 14 Oct 2010 22:14:26 -0700

> But, in http streaming scenario, the ratio of download/upload (from the client's perspective) is much larger than 1. BTW, if
> you keep your chunk duration relatively longer, the amount of requests that you will end up sending will be almost nil
> compared to what you will receive.
> 

You can choose whatever chunk size you wanna use. Does not matter. The fact remains the same. Unless someone uses chunks of a few hundreds of ms, it won't matter.
 
...
> Sorry if "playback time" meant the duration of the playback. I rather meant the start time of the playback. So, if a client
> keeps a larger buffer hoping that it will avoid buffer underruns, this may delay the playback start time.
> 
> [Qin]: Right. So we need to choose approporiate buffer size to seek balance between buffer underflow and startup time
> delay. The buffer size can be changed at any time.

It is not up to me or you. Any implementation (depending on the device, scenario, network type, etc.) can choose any size for the buffer.
 
> [Qin]: I think the presumption is the server should prepare multiple streams of the same content with different bitrates. the
> server may have a big load if the content is live contents.

It is not the server who prepares the content. Not necessarily and not often. So, serving the same content at different bitrates does not pose any extra load on the server (except where the caching comes into play).
 
> Whether it paces the presentation speed down or not in order to avoid buffer underruns is something up to the client. Most
> implementations I have seen simply switch to a lower-bitrate profile well before the buffer is fully drained. So, they don't
> experience buffer underruns and they don’t need to pace the video presentation speed down.
> 
> [Qin]: I don't doubt giving more control to client has its advantages. But I think giving some control to the server also has its
> advantage. e.g.,  you may not need to prepare multiple stream of the same content with different bitrate.

Well, AFAICT the method in which people (including me) are interested in is this so-called multi-bitrate streaming, which implies the same content being encoded at multiple bitrates.

> the server control the transmission rate based on the network condition and client requirements.

How would this work if you have only one bitrate on the server? Is your approach as follows:

Rather than offering the same content encoded at multiple bitrates and serving them based on what the client wants, you wanna serve the content encoded at a single bitrate and by manipulating the transmission rate on the server (based on server's knowledge of network and client), you "adaptively" send it. Is that the scenario you have in mind?

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Fri, 15 Oct 2010 15:14:01 +0800

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Roni Even" <[email-masked]>; "David A. Bryan" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 15, 2010 1:14 PM
Subject: RE: [httpstreaming] Current Status and Our Goal

 [Qin]: Suppose 10 chunks is available at the server side, in the pull model, the client need to send at least 10 requests and receive 10 responses.
          in the push model, the client may only need to send one request and then receive 10 responses.
          comparing with pull, push model save 9 requests.
          also if you look at websocket, push has more lightweight header than pull.
          However as you said:
          "
          if  you keep your chunk duration relatively longer, the amount of requests that you will end up sending will be almost nil
         compared to what you will receive.
          "
          based on your understanding, suppose still 10chunks is avaible at the server side,  in the pull model, the client send 10 request to fetch them and 
          may receive thousands of response. Is it what you said here?
...

[Qin]: I think it is one issue pertain to Buffer management. Since RTP can handle this smoothly, why not HTTP streaming?

[Qin]: Yes, it does not matter whether streaming component is collocated with web server or separated.

[Qin]: I am interested too. But I suspect there are other ways to decrease such overhead. e.g., trancoding may be best choice for live content.

[Qin]: Personally that is what I am trying to look for. a single birate for live content may change at time which can be realized by transcoding.

-acbegen

---

From: Wenbo Zhu <[email-masked]>
Date: Fri, 15 Oct 2010 00:23:18 -0700

Seems we are starting to talk about very specific issues here.
Probably a good idea to start a separate thread, with the existing
arguments summarized?

On Thu, Oct 14, 2010 at 8:22 PM, Qin Wu <[email-masked]> wrote:
> I would like to add my support to the comments below. Specifically, I think
> if the IETF considers work in this area it should focus on the HTTP and TCP
> protocols. Any such work may not be specific to HTTP-streaming (i.e.
> enhancements that are at first motivated by HTTP Streaming may have broader
> applicability, and this should be carefully considered).
> In the draft I do not see a clear or correct identification of the problems.
> For example in the introduction the following are stated as issues:
>
> MW: Several companies, including my employer, are successfully operating
> large scale HTTP streaming systems that do efficiently deliver high-quality
> video content across the Internet, so reality seems to refute this
> statement.
>
> [Qin]: Not sure they can provide the TV experience for all the connected
> devices like smartphones, PCs and tablets. Also not sure they can provide
> the same quality of experence for all the all the connected devices. As we
> discussed in this thread, a minimum of 20 seconds to start your video often
> frustrated users to keep on watching and provide very limited user
> experience.
>
> Can you be more explicit about the problems that you see? I'm not sure where
> the 20s figure comes from. I do not see any problem in supporting startup
> times comparable to TV channel change with adaptive HTTP streaming.
> I am not saying there is no room for improvement in the various deployed
> systems, but I do not see major technical impediments to efficient delivery
> of high quality video using HTTP Streaming.
>
> [Qin]:Not only starup latency but also delay w.r.t. real time streaming. I
> think you negect it becos You didn't get into the discussion list.
>
> On the other hand, I think we should bear in mind HTTP is formerly designed
> for browsing webpage, transport static contents like HTML page, plugin,
> picture, when we are going to use HTTP to deliver real time streaming
> contents, we can not expect to get higher user experience. Therefore the
> current streaming schemes can only offer a better experience over slower
> connections.
>
> MW: It is not clear that segmentation per se is CPU-intensive or has any
> non-negligable effect on bandwidth usage.
>
> [Qin]: Since HTTP streaming server is the combination of streaming server
> and regular web server, I think the answer is both.
>
> [MW] I'm not sure what one of those is. It sounds like it is not a regular
> web server. I think it's an essential feature of modern HTTP streaming that
> it works with regular web infrastructure.
>
> MW: An alternative view is that where quality is degraded due to congestion
> this is due to lack of bandwidth, rather than a lack of QoS guarantees.
> Adaptive HTTP streaming systems adjust the video quality to the available
> bandwidth in order to avoid rebuffering events. It is the available
> bandwidth that needs to be improved to improve quality.
>
> [Qin]: What I emphasize here is with growing popularity of HTTP streaming
> traffic, when thousands or millions of people are accessing the same media
> contents, the big problem we are facing is serious high concurrence access
> issue. The user experience will be greatly affected even you have enough
> available bandwidth. So this is not pure bandwidth issue.
>
> [MW] maybe we mean different things by 'available bandwidth'. Do you think
> it is a server scalability problem, or a network problem ?
>
> [Qin]: please
> read http://www.ietf.org/mail-archive/web/httpstreaming/current/msg00011.html
>
> [MW] Still not sure what you're referring to other than available bandwidth.
> The thread mentions multicast - do you think there remains work to deliver
> HTTP objects over multicast given the work in RMT over the years ?
>
> [Qin]: I don't doubt that adaptive HTTP streaming algorithms can cope with
> bandwidth fluctation. But I hope we can do better.e.g., adaptive HTTP
> streaming algorithms only support delivery of multiple streams of the same
> content with varying quality levels for different bandwidth or devices.
> Howeve how the server in push model or client in pull model can quick
> response to the bitrate changes is a problem we may look at,especially when
> switching beween streams occurs very frequently.
>
> [Qin]: I didn't get what you said. adaptive HTTP streaming algorithms is
> characterized as  client initiated pull model. We are discussing push model
> or how to use pull model with push model.We are talking about different
> model. There are plenty room for IETF to do for this.
>
> [MW] Sorry, I don't understand what the "push" model has to do with HTTP
> Streaming. Are you talking about servers which are not regular HTTP servers
> ? I think this is not what people usually mean when they say "HTTP
> streaming" - you should rename the work if that is the case.
>
> MW: This is simply not correct, since there are hundreds of examples of
> devices which support trick-play using HTTP streaming techniques without
> storing the whole content on the users device.
>
> [Qin]: Fast forward capabilty is not the most important feature we are
> looking for. However I am hard to believe existing HTTP streaming techniques
> can provide the same degree of playbackcontrol that DVD player can provides
> or RTSP protocol provides. E.g., In the adaptive HTTP streaming algorithms,
> the trick play is limited to pause/resume/stop by driving the HTTP request.
> If the contents hasn't been dowloaded and the consume want fast forward, the
> HTTP client needs to issue another new HTTP request to fetch the contents
> which willcause unacceptable latency to the consumer.
>
> [MW] Again, the experience of millions of existing customers refutes what
> you claim. Why do you think it is necessarily so slow to issue a new HTTP
> request for a different part of the content?
>
> [Qin]: You didn't see the reaon behind this, becos the existing customers
> has no choice when they view live streaming, what they can get is close to
> live experience rather than real time user experience. Operatoer do nothing
> for their network to make http streaming more controllable and managable.
> Therefore more and more consumer tend to choose non-live content. that's why
> we see more and more non-live content consumers rather than live contents
> consumers.
>
> A first step in considering what, if any, work should be done here might be
> to contact those organizations which are standardizing the higher layers of
> HTTP streaming systems (e.g. manifest and file formats) and ask whether
> there are deficiencies they see in IETF protocols that could be usefully
> addressed by the IETF. What I think we should avoid in the IETF is
> duplicating the work of these other bodies.
>
> Best,
>
> Mark Watson
>
> Netflix Inc.
>
>
>
> I imagine the only work the IETF should do (if we decide to) is the
> transport and HTTP-layer optimization for better streaming performance.
>
> -acbegen
>
> Lars
>

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 15 Oct 2010 03:32:33 -0400

> > [Qin]: I don't doubt giving more control to client has its 
> advantages. 
> > But I think giving some control to the server also has its 
> advantage. e.g.,  you may not need to prepare multiple stream 
> of the same content with different bitrate.
> 
> Well, AFAICT the method in which people (including me) are 
> interested in is this so-called multi-bitrate streaming, 
> which implies the same content being encoded at multiple bitrates.
> 
> > the server control the transmission rate based on the 
> network condition and client requirements.
> 
> Rather than offering the same content encoded at multiple 
> bitrates and serving them based on what the client wants, you 
> wanna serve the content encoded at a single bitrate and by 
> manipulating the transmission rate on the server (based on 
> server's knowledge of network and client), you "adaptively" 
> send it. Is that the scenario you have in mind?

I guess what Qin had in mind is something called "dynamic mode" of HTTP
streaming, wherein there can be just one file containing all alternatives
(i.e. multiple bitrates, resolutions, frame rates, etc.), as what can be
stored in ISO base media file format, but the Media Presentation Description
(MPD, i.e. manifest) describes the content as if it was fragmented,
segmented and stored in multiple files/URLs. Upon receiving a request of a
segment, the server creates the segment on-the-fly. Thus, caches and clients
work as determined by the HTTP streaming spec (e.g. MPEG DASH or 3GPP AHS),
but the server needs enhanced capability (and thus the mode can also be
called server-enhancing mode). However, there seems no need to specify
anything (as a standard) to do this.

BR, YK

> Sent: Friday, October 15, 2010 1:14 AM
> To: Qin Wu; Roni Even; David A. Bryan
> > But, in http streaming scenario, the ratio of download/upload (from 
> > the client's perspective) is much larger than 1. BTW, if 
> you keep your 
> > chunk duration relatively longer, the amount of requests 
> that you will end up sending will be almost nil compared to 
> what you will receive.
> > 
> You can choose whatever chunk size you wanna use. Does not 
> matter. The fact remains the same. Unless someone uses chunks 
> of a few hundreds of ms, it won't matter.
>  
> ...
> > Sorry if "playback time" meant the duration of the 
> playback. I rather 
> > meant the start time of the playback. So, if a client keeps 
> a larger buffer hoping that it will avoid buffer underruns, 
> this may delay the playback start time.
> > 
> > [Qin]: Right. So we need to choose approporiate buffer size to seek 
> > balance between buffer underflow and startup time delay. 
> The buffer size can be changed at any time.
> 
> It is not up to me or you. Any implementation (depending on 
> the device, scenario, network type, etc.) can choose any size 
> for the buffer.
>  
> > Or, the client can start the playback quickly and build the 
> buffer over time by requesting lower-bitrate chunks.
> > 
> > [Qin]: I think the presumption is the server should prepare 
> multiple 
> > streams of the same content with different bitrates. the 
> It is not the server who prepares the content. Not 
> necessarily and not often. So, serving the same content at 
> different bitrates does not pose any extra load on the server 
> (except where the caching comes into play).
>  
> > Whether it paces the presentation speed down or not in 
> order to avoid 
> > buffer underruns is something up to the client. Most 
> implementations I 
> > have seen simply switch to a lower-bitrate profile well 
> before the buffer is fully drained. So, they don't experience 
> buffer underruns and they don't need to pace the video 
> presentation speed down.
> > 
> > [Qin]: I don't doubt giving more control to client has its 
> advantages. 
> > But I think giving some control to the server also has its 
> advantage. e.g.,  you may not need to prepare multiple stream 
> of the same content with different bitrate.
> 
> Well, AFAICT the method in which people (including me) are 
> interested in is this so-called multi-bitrate streaming, 
> which implies the same content being encoded at multiple bitrates.
> 
> > the server control the transmission rate based on the 
> network condition and client requirements.
> 
> Rather than offering the same content encoded at multiple 
> bitrates and serving them based on what the client wants, you 
> wanna serve the content encoded at a single bitrate and by 
> manipulating the transmission rate on the server (based on 
> server's knowledge of network and client), you "adaptively" 
> send it. Is that the scenario you have in mind?
> 
> -acbegen

---

From: Qin Wu <[email-masked]>
Date: Fri, 15 Oct 2010 16:08:51 +0800

No, we are talking about difference between pull model and push model and their advantage, disavantages.
The model specified in 3GPP is just client based pull model which gives client the whole control to handle playout.
Another model we need to look at is push model. The technolgoies related to this model  are server push technology, websocket protcol. 
The difference between them is:
pull model is client based solution, rely on existing web infrastructure including cache behavior, require nothing from network. 

push model network based solution, network should be enhanced to provide better transport and satisfy better QOE.

Also I would like to point out what 3GPP is doing for this pull model is just standardizing manifest component, which is similar
to Apple's draft-pantos-http-live-streaming-04 and specify how these component work in the pull model.

However in the push model, this component is not neccessary. 
Also in the push model, the cache may be enhanced as pointed out by Wenbo Zhu.

Regards!
-Qin

---

From: Qin Wu <[email-masked]>
Date: Fri, 15 Oct 2010 16:47:51 +0800

Sounds like a good idea to me, it seems we are buried into this single thread and hard for us to follow this discussion.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 15 Oct 2010 09:57:16 +0100

>          also if you look at websocket, push has more lightweight header than pull.

However, unless the request/response time or the volume of requests per server is a significant bottleneck in the system then saving some requests doesn't provide any advantages.

Ben

---

From: Qin Wu <[email-masked]>
Date: Fri, 15 Oct 2010 17:02:54 +0800

Thank you for separate this issue out.
----- Original Message ----- 
From: "Ben Niven-Jenkins" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 15, 2010 4:57 PM
Subject: Push Vs Pull (was Re: [httpstreaming] Current Status and Our Goal)

[Qin]: Good point. Such bottleneck could happen in case of concurrence of thousands of consumers accessing the same content. 

Ben

---

From: Mark Watson <[email-masked]>
Date: Fri, 15 Oct 2010 02:43:55 -0700

All,

Now that it is clearer what technology some of the participants here would like to consider (namely the so-called "push model"), I think it would be reasonable to ask what specific standards they think are missing to implement and deploy this technology ? What work should the IETF do ? Is it proposed to restrict the scope to this "push model" ? (which might be reasonable, since I do not think additional standards work is required in IETF to support so-called "pull model").

Whatever work is proposed it is worth noting that the industry trend is very much towards the "pull model". Far more media is being delivered in an adaptive way with that model than with the "push model". This point might be considered when priortising this work.

Neverthless, for the push model there are already multiple standards for media delivery over a single HTTP connection and multiple deployed products which do this, including adaptation of the video rate, by transcoding, switching or otherwise. You could look at Adobe Flash for example. For real-time adaptation from a single source you could look at Ortiva or Vantrix. I'm sure there are others.

...Mark

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 15 Oct 2010 03:37:13 -0700

> Sent: Friday, October 15, 2010 3:14 AM
> You can choose whatever chunk size you wanna use. Does not matter. The fact remains the same. Unless someone uses
> chunks of a few hundreds of ms, it won't matter.
> 

You missed my point. The size of the 10 request messages you sent in the example above is not much compared to the size of the 10 chunks you receive. And if the chunk duration gets larger, the difference will be even bigger.

> [Qin]: I think it is one issue pertain to Buffer management. Since RTP can handle this smoothly, why not HTTP streaming?

Sorry I am not following. RTP does not deal with this. Maybe you are referring to RTSP streaming and then buffer duration is again something chosen by the client not the protocol.
 
> It is not the server who prepares the content. Not necessarily and not often. So, serving the same content at different bitrates
> does not pose any extra load on the server (except where the caching comes into play).
> 
> Well, AFAICT the method in which people (including me) are interested in is this so-called multi-bitrate streaming, which
> implies the same content being encoded at multiple bitrates.
> 
> Rather than offering the same content encoded at multiple bitrates and serving them based on what the client wants, you
> wanna serve the content encoded at a single bitrate and by manipulating the transmission rate on the server (based on
> server's knowledge of network and client), you "adaptively" send it. Is that the scenario you have in mind?
> 

If you are saying a server doing transcoding for adaptation scales better than an http server serving client requests for different chunks, then I think you should make your arguments clear enough in the problem statement draft and see whether others think. To me, it is a losing proposition. 

-acbegen

---

From: Ning Zong <[email-masked]>
Date: Sat, 16 Oct 2010 08:31:02 +0800

Hi, Mark,

Please see in-line...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Mark Watson
Sent: Friday, October 15, 2010 5:44 PM
To: Qin Wu
Cc: [email-masked]
Subject: Re: [httpstreaming] Push Vs Pull (was Re: Current Status and Our
Goal)

All,

Now that it is clearer what technology some of the participants here would
like to consider (namely the so-called "push model"), I think it would be
reasonable to ask what specific standards they think are missing to
implement and deploy this technology ? What work should the IETF do ? Is it
proposed to restrict the scope to this "push model" ? (which might be
reasonable, since I do not think additional standards work is required in
IETF to support so-called "pull model").

[ZN] Although I agree that restricting to "push mode" might be good, I can
not agree that there is no additional work to do in IETF around "pull mode".
We are also talking about if there is any issue related to network transport
need to be improved in the scenario of HTTP streaming - which is not push or
pull problem.

Whatever work is proposed it is worth noting that the industry trend is very
much towards the "pull model". Far more media is being delivered in an
adaptive way with that model than with the "push model". This point might be
considered when priortising this work.

[ZN] Again, I don't think the adaptive way has any "stronger" relation with
pull mode.

Neverthless, for the push model there are already multiple standards for
media delivery over a single HTTP connection and multiple deployed products
which do this, including adaptation of the video rate, by transcoding,
switching or otherwise. You could look at Adobe Flash for example. For
real-time adaptation from a single source you could look at Ortiva or
Vantrix. I'm sure there are others.

[ZN] Thank you for providing these pointers...

...Mark

On Oct 15, 2010, at 5:02 PM, Qin Wu wrote:

>>> But, in http streaming scenario, the ratio of download/upload (from the
client's perspective) is much larger than 1. BTW, if
>>> you keep your chunk duration relatively longer, the amount of requests
that you will end up sending will be almost nil
>> You can choose whatever chunk size you wanna use. Does not matter. The
fact remains the same. Unless someone uses chunks of a few hundreds of ms,
it won't matter.
>> 
>> [Qin]: Suppose 10 chunks is available at the server side, in the pull
model, the client need to send at least 10 requests and receive 10
responses.
> However, unless the request/response time or the volume of requests per
server is a significant bottleneck in the system then saving some requests
doesn't provide any advantages.
> 
> [Qin]: Good point. Such bottleneck could happen in case of concurrence of
thousands of consumers accessing the same content.

---

From: Qin Wu <[email-masked]>
Date: Mon, 18 Oct 2010 13:45:04 +0800

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Roni Even" <[email-masked]>; "David A. Bryan" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 15, 2010 6:37 PM
Subject: RE: [httpstreaming] Current Status and Our Goal

[Qin]:  Good point, but I think the size of 10 request messages may be not  count, but the timing of response is controlled by these 10 request message which may be hard to satisfy the real time streaming requirements for 
latency.

[Qin]:Al though the client control the buffer duration for playout at the client side, the client can not control the buffer for encoding at the server side.

[Qin]: Okay. thank for pointing out this.

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Mon, 18 Oct 2010 15:22:38 +0800

[Qin]; for the live content consuming with thousands of consumers viewing at the same time, in my opinion, it may be a successful propsotion.

---

From: Thomas Stockhammer <[email-masked]>
Date: Mon, 18 Oct 2010 09:29:55 +0200

> [Qin]; for the live content consuming with thousands of consumers viewing at the same time, in my opinion, it may be a successful propsotion.

[T] Adaptation for each of the thousands of users!?  [\T]

---
Dr. Thomas Stockhammer (CEO) || [email-masked] || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.

---

From: Qin Wu <[email-masked]>
Date: Mon, 18 Oct 2010 15:42:04 +0800

----- Original Message ----- 
From: "Thomas Stockhammer" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Ali C. Begen (abegen)" <[email-masked]>; "Roni Even" <[email-masked]>; "David A. Bryan" <[email-masked]>; <[email-masked]>
Sent: Monday, October 18, 2010 3:29 PM
Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal

[Qin]: The scenario we are talking about is more and more people watching one popuar global event at the same time, e.g., world cup finals, US president election, Olympic games.

---

---

From: Thomas Stockhammer <[email-masked]>
Date: Mon, 18 Oct 2010 09:58:23 +0200

> [Qin]: The scenario we are talking about is more and more people watching one popuar global event at the same time, e.g., world cup finals, US president election, Olympic games.

[T] 
Exactly! And therefore individual server side adaptation is worst ... 
To maintain a 1-1 relationship between the client and the server breaks scalability. 
Just offer a couple of bitrate choices and the millions of clients will pick the one that suits them. Clients are extremely intelligent and capable nowadays. 
Network-initiated individual QoS control is not a subject in HTTP streaming. 
[\T] 

---

---

From: Qin Wu <[email-masked]>
Date: Mon, 18 Oct 2010 16:13:52 +0800

----- Original Message ----- 
From: "Thomas Stockhammer" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Ali C. Begen (abegen)" <[email-masked]>; "Roni Even" <[email-masked]>; "David A. Bryan" <[email-masked]>; <[email-masked]>
Sent: Monday, October 18, 2010 3:58 PM
Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal

[T] 

[Qin]: It seems you talk about server based solution in your vision which I can't follow. In my understanding, client based solution more fit for recorded content consuming than live content consuming.
The big problem of current existing client based solution can not well satisfy real time streaming requirements during live content consuming.

---

---

From: Thomas Stockhammer <[email-masked]>
Date: Mon, 18 Oct 2010 10:34:01 +0200

> The big problem of current existing client based solution can not well satisfy real time streaming requirements during live content consuming.

[T]
If I summarize your proposition from the above e-mails, this is what it says:
"[Qin:] Rather than offering the same content encoded at multiple bitrates and serving them based on what the client wants, you wanna serve the content encoded at a single bitrate and by manipulating the transmission rate on the server (based on server's knowledge of network and client), you "adaptively" send it. That is what I am trying to look for. a single birate for live content may change at time which can be
realized by transcoding. This is a successful propsotion for the live content consuming with thousands of consumers viewing at the same time"

This is server-controlled: "... by manipulating the transmission rate on the server ..." And in my opinion this is no successful proposition.

The only problem in live that may exist is end-to-end latency. 
[\T]

---

---

From: Wenbo Zhu <[email-masked]>
Date: Mon, 18 Oct 2010 01:41:23 -0700

> The big problem of current existing client based solution can not well satisfy real time streaming requirements during live content consuming.

I'd suggest we focus on the unique challenges that HTTP brings, i.e.
as a transport protocol, such as it enforces strict client-server RPC
and has to live with intermediaries such as proxy. Discussions on
specific client, network, or server designs in the general context of
media streaming over Internet, IMO, are mostly irrelevant.

- Wenbo

---

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Oct 2010 18:16:47 +0100

On 15 Oct 2010, at 08:14, Qin Wu wrote:
> [Qin]: Suppose 10 chunks is available at the server side, in the pull model, the client need to send at least 10 requests and receive 10 responses. in the push model, the client may only need to send one request and then receive 10 responses. comparing with pull, push model save 9 requests. also if you look at websocket, push has more lightweight header than pull.

This is true.  However, by changing to a push model, you also move the responsibility for maintaining state for rate adaptation to the server, rather than the client.  The extra state, and the complexity of running the rate adaptation algorithm, almost certainly outweighs the savings from reduced request processing.

-- 
Colin Perkins
http://csperkins.org/

---

From: David R Oran <[email-masked]>
Date: Tue, 19 Oct 2010 13:46:35 -0400

> This is true.  However, by changing to a push model, you also move the responsibility for maintaining state for rate adaptation to the server, rather than the client.  The extra state, and the comp…
That is debatable. I personally side with Colin in such a debate, but there are people who do make credible arguments on the other side, and people who ship cost-effective and arguably scalable systems that work that way.

What I wonder is if the IETF is a productive venue to hold that debate. I suspect not.
The IETF never was able to stop IMS, and the ITU was never able to stop the Internet, hard as both tried.

Cheers, DaveO.

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Tue, 19 Oct 2010 23:08:17 +0100

> That is debatable. I personally side with Colin in such a debate, but there are people who do make credible arguments on the other side, and people who ship cost-effective and arguably scalable sys…

While that may be true, I doubt they're based on HTTP.

I thought the pretence of creating this list was to discuss if there was work that IETF could do to improve "HTTP streaming". Changing the fundamental model from pull to push is not improving HTTP streaming it's creating a whole new streaming protocol, which might be a valid thing to do but is a completely different discussion IMO.

Ben

---

From: Thomas Stockhammer <[email-masked]>
Date: Wed, 20 Oct 2010 00:09:53 +0200

+1

---

---

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Oct 2010 23:47:44 +0100

> I thought the pretence of creating this list was to discuss if there was work that IETF could do to improve "HTTP streaming". Changing the fundamental model from pull to push is not improving HTTP…

That depends on how narrow a view you take of "HTTP streaming". There are certainly ways in which one can building adaptive streaming video systems that push media data over a single HTTP connection with sender controlled rate switching. Is the aim of this list to discuss HTTP streaming in the general case, or only one particular, pull-based, incarnation of it? 

-- 
Colin Perkins
http://csperkins.org/

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 20 Oct 2010 01:17:25 -0500

----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Benjamin Niven-Jenkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 19, 2010 5:47 PM
Subject: Re: [httpstreaming] Current Status and Our Goal

>>>>>> the client's perspective) is much larger than 1. BTW, if you keep 
>>>>>> your chunk duration relatively longer, the amount of requests that 
>>>>>> you will end up sending will be almost nil compared to what you will 
>>>>>> receive.
>>>>>>
>>>>> fact remains the same. Unless someone uses chunks of a few hundreds of 
>>>>> ms, it won't matter.
>>>>>
>>>>> responses. in the push model, the client may only need to send one 
>>>>> request and then receive 10 responses. comparing with pull, push model 
>>>>> save 9 requests. also if you look at websocket, push has more 
>>>>> lightweight header than pull.
>>>>
>>>> This is true.  However, by changing to a push model, you also move the 
>>>> responsibility for maintaining state for rate adaptation to the server, 
>>>> rather than the client.  The extra state, and the complexity of running 
>>>> the rate adaptation algorithm, almost certainly outweighs the savings 
>>>> from reduced request processing.
>>>>
>>> That is debatable. I personally side with Colin in such a debate, but 
>>> there are people who do make credible arguments on the other side, and 
>>> people who ship cost-effective and arguably scalable systems that work 
>>> that way.
>>
>> I thought the pretence of creating this list was to discuss if there was 
>> work that IETF could do to improve "HTTP streaming". Changing the 
>> fundamental model from pull to push is not improving HTTP streaming it's 
>> creating a whole new streaming protocol, which might be a valid thing to 
>> do but is a completely different discussion IMO.
>
>
> That depends on how narrow a view you take of "HTTP streaming". There are 
> certainly ways in which one can building adaptive streaming video systems 
> that push media data over a single HTTP connection with sender controlled 
> rate switching. Is the aim of this list to discuss HTTP streaming in the 
> general case, or only one particular, pull-based, incarnation of it?

To land somewhere between Colin and Ben, it would be helpful to decide how 
much the general-case HTTP model can change before it is no longer HTTP, but 
some other protocol.

If I'm understanding the discussion to date, we're somewhere close to

Normal HTTP                   Also under discussion on this list
================================================================
client-initiated (pull)       server-initiated (push)
unicast                       multicast
unmodified proxies            modified proxies
unmodified servers            modified servers

Is this the way other people think the discussion has gone?

What else did I miss?

Thanks,

Spencer

---

From: Wenbo Zhu <[email-masked]>
Date: Tue, 19 Oct 2010 23:28:55 -0700

Nice call .. as I had found it difficult to follow this thread.

> Normal HTTP                   Also under discussion on this list

HTTP never has problems to support push (as efficient as you can
possibly do with TCP), out of its native semantics. Most known issues
are related to browsers or proxies. Unless you are talking about p2p
style of push, which requires the client to expose its own end-point,
then there is not much to explore at the transport level. Or if we are
talking about pull vs push at the application level, then we need make
sure the transport is involved, as otherwise it's simply becoming a
design/system issue.

On Tue, Oct 19, 2010 at 11:17 PM, Spencer Dawkins
<[email-masked]> wrote:
>
> ----- Original Message ----- From: "Colin Perkins" <[email-masked]>
>>>>>> ----- Original Message ----- From: "Ali C. Begen (abegen)"
>>>>>> <[email-masked]>
>>>>>>
>>>>>>> the client's perspective) is much larger than 1. BTW, if you keep your chunk
>>>>>>> duration relatively longer, the amount of requests that you will end up
>>>>>>> sending will be almost nil compared to what you will receive.
>>>>>>>
>>>>>> responses. in the push model, the client may only need to send one request
>>>>>> and then receive 10 responses. comparing with pull, push model save 9
>>>>>> requests. also if you look at websocket, push has more lightweight header
>>>>>> than pull.
>>>>>
>>>>> rather than the client.  The extra state, and the complexity of running the
>>>>> rate adaptation algorithm, almost certainly outweighs the savings from
>>>>> reduced request processing.
>>>>>
>>>> people who ship cost-effective and arguably scalable systems that work that
>>>> way.
>>>
>>> creating a whole new streaming protocol, which might be a valid thing to do
>>> but is a completely different discussion IMO.
>>
>>

---

From: Ning Zong <[email-masked]>
Date: Wed, 20 Oct 2010 16:49:47 +0800

IMO, the issue may not only related to multicast or unicast, but the QoE
improvement (e.g. reduce the startup time after user change the channel). If
I remember correctly, in the motivation of FCC in AVT, one important concern
is that the Retransmission server can store the most recent GoPs and feed
them to the client with faster rate than playback to effectively fill the
gap between the time point of user channel zapping and next complete GoP.
This improvement also applies to unicast based HTTP streaming, right?
The above concern also implies that adding some intelligence to
intermediaries would improve the streaming performance of HTTP streaming
system. To be more specific, having a deep look at the mechanisms of
distinguish different types of HTTP traffic (e.g. live streaming with higher
timing requirement v.s. normal packet, streaming packet containing I-frame
worthy of caching for further usage v.s. normal streaming packet) would be a
possible direction for consideration in this list.

My two cents.

BR,
Ning Zong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ali C. Begen (abegen)
Sent: Thursday, October 07, 2010 6:15 AM
To: Roni Even; David A. Bryan; Qin Wu
Cc: [email-masked]
Subject: Re: [httpstreaming] Current Status and Our Goal

> change and I think this is relevant also in this case.

Are you assuming a multicast environment for http streaming? Ow, the startup
issue is not an issue in unicast connections.

-acbegen

---

From: Ning Zong <[email-masked]>
Date: Wed, 20 Oct 2010 17:46:06 +0800

Sorry, to be clear, the FCC concern I consider here is limited to live
streaming scenario.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ning Zong
Sent: Wednesday, October 20, 2010 4:50 PM
To: 'Ali C. Begen (abegen)'; 'Roni Even'; 'David A. Bryan'; 'Qin Wu'
Cc: [email-masked]
Subject: Re: [httpstreaming] Current Status and Our Goal

My two cents.

BR,
Ning Zong

-----Original Message-----

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Oct 2010 04:21:58 -0700

When the traffic is unicast, you don't have the problems we have in a multicast environment. The unicast traffic will naturally start from a random access point. You might need some initialization data to start decoding or whatever, but all that comes from the server over unicast anyway. The same applies to both on-demand and live content. 

-acbegen

> From: Ning Zong [mailto:[email-masked]]
> Sent: Wednesday, October 20, 2010 11:50 AM
> To: Ali C. Begen (abegen); 'Roni Even'; 'David A. Bryan'; 'Qin Wu'

---

From: Ning Zong <[email-masked]>
Date: Wed, 20 Oct 2010 20:18:46 +0800

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Wednesday, October 20, 2010 7:22 PM
To: Ning Zong; Roni Even; David A. Bryan; Qin Wu
Cc: [email-masked]
Subject: RE: [httpstreaming] Current Status and Our Goal

When the traffic is unicast, you don't have the problems we have in a
multicast environment. The unicast traffic will naturally start from a
random access point.
[ZN]: I am a little bit confused by the word "naturally". Do you mean the
unicast server will adjust the timing such that the starting packet/segment
will always begin with RAP? In fact, not all the HTTP streaming system
mandates that the segmentation should align with RAP.

 You might need some initialization data to start decoding or whatever, but
all that comes from the server over unicast anyway. 
[ZN]: right, but the reference information is not always available to be
transmitted at any time point even using unicast, unless there is a cache
point.

The same applies to both on-demand and live content. 

-acbegen

> From: [email-masked]
[mailto:[email-masked]]
> Are you assuming a multicast environment for http streaming? Ow, the
startup

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Oct 2010 05:41:49 -0700

> Sent: Wednesday, October 20, 2010 3:19 PM

Then, that's a pretty poor segmentation or the client simply downloads data that it will discard. The point is the connection is unicast so the client gets what it needs.
 
> transmitted at any time point even using unicast, unless there is a cache

? That reference information is part of the data the client gets. A cache cannot produce that data by itself, it needs to see it from upstream, which means it previously came from the origin server. 

My point is that the ret. server we had in RAMS is not needed here since all the servers that can serve the client is one such entity here. They provide what the client wants, and if they don't have it, they redirect the client or fetch it for the client.

-acbegen

---

From: Ning Zong <[email-masked]>
Date: Thu, 21 Oct 2010 08:38:44 +0800

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Wednesday, October 20, 2010 8:42 PM
To: Ning Zong; Roni Even; David A. Bryan; Qin Wu
Cc: [email-masked]
Subject: RE: [httpstreaming] Current Status and Our Goal

> mandates that the segmentation should align with RAP.

Then, that's a pretty poor segmentation or the client simply downloads data
that it will discard. The point is the connection is unicast so the client
gets what it needs.
 
> transmitted at any time point even using unicast, unless there is a cache

? That reference information is part of the data the client gets. A cache
cannot produce that data by itself, it needs to see it from upstream, which
means it previously came from the origin server. 
[ZN]: I agree that the RI is part of the data acquired by the client, but
the point is - if every segment carries all the necessary RI? I guess no. So
I am just wondering if there is space to reduce the startup delay in client
side.

My point is that the ret. server we had in RAMS is not needed here since all
the servers that can serve the client is one such entity here. They provide
what the client wants, and if they don't have it, they redirect the client
or fetch it for the client.
[ZN]: The last sentence implies some architecture concerns, and
interesting...

-acbegen
 
> > improvement (e.g. reduce the startup time after user change the
channel).
> If
> > worthy of caching for further usage v.s. normal streaming packet) would
be
> a