Re: [httpstreaming] Current Status and Our Goal

[Wenbo Zhu <[e-mail]>]

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

> Normal HTTP                   Also under discussion on this list
> ================================================================
> client-initiated (pull)       server-initiated (push)

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
<[e-mail]> wrote:
>
> ----- 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
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming
>