Re: [httpstreaming] Current Status and Our Goal

[Benjamin Niven-Jenkins <[e-mail]>]

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.

Ben