Re: [httpstreaming] [dispatch] Q-HTTP

Marshall,

It is over-provisioned if a large percentage of time, the majority of
capacity is sitting idle, versus time-shifting applications flows that
can be time shifted.

FEC does absolutely nothing to solve the latency and jitter issue.

Mike

-----Original Message-----
From: Marshall Eubanks [mailto:tme@americafree.tv] 
Sent: Tuesday, November 16, 2010 11:43 AM
To: Mike Hammer (hmmr)
Cc: Mark Watson; Kathy McEwen; dispatch@ietf.org; httpstreaming;
conex@ietf.org; Ingemar Johansson S; GARCIA ARANDA, JOSEJAVIER (JOSE
JAVIER)
Subject: Re: [httpstreaming] [dispatch] Q-HTTP

On Nov 10, 2010, at 10:05 AM, Mike Hammer (hmmr) wrote:

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

It is a mistake to call it over-provisioning. (Anything needed for
proper performance I would call proper provisioning.) And, of course,
the
customers pay for it. (It is interesting that no one ever seems to ask
who pays for QOS.)

It is a question of where is it better to put resources, and I think
that there is a long history to show that in many (not all) situations
it is better to put resources in provisioning than in QOS. 

I also think that a modest amount of FEC would go a long way  to address
concerns about real-time traffic, and I surprised that this is not
already used routinely. 

Regards
Marshall 

> 
> 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
> _______________________________________________
> httpstreaming mailing list
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming
> 