Re: [httpstreaming] Current Status and Our Goal

[Colin Perkins <[e-mail]>]

On 15 Oct 2010, at 08:14, Qin Wu wrote:
> ----- Original Message ----- 
> From: "Ali C. Begen (abegen)" <[e-mail]>
> To: "Qin Wu" <[e-mail]>; "Roni Even" <[e-mail]>; "David A. Bryan" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Friday, October 15, 2010 1:14 PM
> Subject: RE: [httpstreaming] Current Status and Our Goal
> 
> 
>> 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.

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