Re: [httpstreaming] Current Status and Our Goal

["Spencer Dawkins" <[e-mail]>]

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


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

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