Re: [httpstreaming] Push Vs Pull (was Re: Current Status and Our Goal)

Hi, Mark,

Please see in-line...

-----Original Message-----
From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org]
On Behalf Of Mark Watson
Sent: Friday, October 15, 2010 5:44 PM
To: Qin Wu
Cc: httpstreaming@ietf.org
Subject: Re: [httpstreaming] Push Vs Pull (was Re: Current Status and Our
Goal)

All,

Now that it is clearer what technology some of the participants here would
like to consider (namely the so-called "push model"), I think it would be
reasonable to ask what specific standards they think are missing to
implement and deploy this technology ? What work should the IETF do ? Is it
proposed to restrict the scope to this "push model" ? (which might be
reasonable, since I do not think additional standards work is required in
IETF to support so-called "pull model").

[ZN] Although I agree that restricting to "push mode" might be good, I can
not agree that there is no additional work to do in IETF around "pull mode".
We are also talking about if there is any issue related to network transport
need to be improved in the scenario of HTTP streaming - which is not push or
pull problem.

Whatever work is proposed it is worth noting that the industry trend is very
much towards the "pull model". Far more media is being delivered in an
adaptive way with that model than with the "push model". This point might be
considered when priortising this work.

[ZN] Again, I don't think the adaptive way has any "stronger" relation with
pull mode.

Neverthless, for the push model there are already multiple standards for
media delivery over a single HTTP connection and multiple deployed products
which do this, including adaptation of the video rate, by transcoding,
switching or otherwise. You could look at Adobe Flash for example. For
real-time adaptation from a single source you could look at Ortiva or
Vantrix. I'm sure there are others.

[ZN] Thank you for providing these pointers...

...Mark

On Oct 15, 2010, at 5:02 PM, Qin Wu wrote:

> Thank you for separate this issue out.
> ----- Original Message ----- 
> From: "Ben Niven-Jenkins" <ben@niven-jenkins.co.uk>
> To: "Qin Wu" <sunseawq@huawei.com>
> Cc: <httpstreaming@ietf.org>
> Sent: Friday, October 15, 2010 4:57 PM
> Subject: Push Vs Pull (was Re: [httpstreaming] Current Status and Our
Goal)
> 
> 
> 
> On 15 Oct 2010, at 08:14, Qin Wu wrote:
> 
>> From: "Ali C. Begen (abegen)" <abegen@cisco.com>
>> 
>>> 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.
> 
> However, unless the request/response time or the volume of requests per
server is a significant bottleneck in the system then saving some requests
doesn't provide any advantages.
> 
> [Qin]: Good point. Such bottleneck could happen in case of concurrence of
thousands of consumers accessing the same content. 
> 
> Ben
> _______________________________________________
> httpstreaming mailing list
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming
> 

_______________________________________________
httpstreaming mailing list
httpstreaming@ietf.org
https://www.ietf.org/mailman/listinfo/httpstreaming