Re: [httpstreaming] [dispatch] Q-HTTP

Nice theory.  Until it gets down to who is going to pay for the
over-provisioning.

Is the ARPU going to go up?  Are content distributors willing to pay
more to send that data?

Also, note how the volume of traffic always seems to expand to fill the
BW available.

Mike

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Mark Watson
Sent: Tuesday, November 09, 2010 11:19 PM
To: Kathy McEwen
Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson
S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER)
Subject: Re: [dispatch] [httpstreaming] Q-HTTP

Sent from my iPad

On Nov 9, 2010, at 7:01 PM, "Kathy McEwen"
<kathy@iridescentnetworks.com> wrote:

> One problem with the voice analogy is that the sheer volume of data
> traversing the web today is not driven by voice...it's video...and
it's not
> even a fraction of the viewing that folks are doing of broadcast
content.  A
> solution that depends on "simply" having too much bandwidth, is that
someone
> is paying for it.  Eventually it hits someone's pocket books....and if
there
> isn't sufficient revenue to cover the costs, the too much does
degrade.
> Today the mass media is consumed via cheap broadcast technologies...
why
> shouldn't the web (fixed and mobile) be as cheap AND as good??  
> 

It should, the question is what is the cheapest way to do it. QoS is
expensive too. I tend to agree with the thesis below that history is
telling us that avoiding scarcity in the first place is cheaper than
rationing here.

...Mark

> -----Original Message-----
> From: httpstreaming-bounces@ietf.org
[mailto:httpstreaming-bounces@ietf.org]
> On Behalf Of Lars Eggert
> Sent: Tuesday, November 09, 2010 8:02 PM
> To: David Singer
> Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER);
> httpstreaming; dispatch@ietf.org; conex@ietf.org
> Subject: Re: [httpstreaming] [dispatch] Q-HTTP
> 
> On 2010-11-9, at 18:31, David Singer wrote:
>> It is that there are two ways to solve a real-time bandwidth need.
One is
> to reserve bandwidth, manage QoS and so on;  one gets protocols and
systems
> like diffserv, ATM, and so on.  The other is simply to have 'too much'
of
> the resource.  Though it feels wrong, the latter often ends up being
the
> cheaper and easier solution.  So, for example, voice over IP is
getting used
> quite a lot, and to good effect, on the internet today not because we
have
> successfully deployed any bandwidth reservation or QoS management
protocols
> and systems, but because the available bandwidth is, for the most
part,
> greatly in excess of what is needed, and the systems can adapt in
real-time
> to what they get (rather than asking for what they want).  The same is
true
> for multimedia delivery;  the complexity of RTP + TCP friendliness +
QoS
> management is not worth it compared to having adaptable end-systems
and
> overall more bandwidth than needed.
> 
> Fully agreed. 
> 
> Folks who like pictures can take a look at
> https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much
the same
> argument.
> 
> Lars
> 
> _______________________________________________
> httpstreaming mailing list
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming
> 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch