Re: [httpstreaming] Current Status and Our Goal

[Colin Perkins <[e-mail]>]

On 19 Oct 2010, at 23:08, Benjamin Niven-Jenkins wrote:
> On 19 Oct 2010, at 18:46, David R Oran wrote:
>> 
>> On Oct 19, 2010, at 1:16 PM, Colin Perkins wrote:
>>> On 15 Oct 2010, at 08:14, Qin Wu wrote:
>>>> ----- Original Message ----- 
>>>> From: "Ali C. Begen (abegen)" <[e-mail]>
>>>> 
>>>>> 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.
>>>>> 
>>>>> [Qin]: No, I just compare pull and push with the same chunk duration.
>>>> 
>>>> 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. 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.
> 
> 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.


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/