Re: [httpstreaming] [dispatch] Q-HTTP

["Mike Hammer (hmmr)" <[e-mail]>]

David,

It is possible we have different usage scenarios in mind and could be
talking past one another.  There are lots of variables.  Is this
unicast, multicast, broadcast, full-duplex, interactive, mixtures of
high and low BW, latency-sensitive and not, very bursty and not, where
the sources of content are, how many sources, P2P or not, etc.  And all
of these dynamically interact on the network.  Some subset of
applications may be able to play nicely on a BE network.  But, I am just
being cautions to not extrapolate that to all applications.  In some
cases, the QoS may be worth the management and cost proportional to its
usage.  So, maybe this is just an issue of scoping the application of
the solution to the subset of traffic known to behave well.

Mike


-----Original Message-----
From: David Singer [mailto:[e-mail]] 
Sent: Wednesday, November 10, 2010 11:27 AM
To: Mike Hammer (hmmr)
Cc: Mark Watson; Kathy McEwen; [e-mail]; httpstreaming;
[e-mail]; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA,
JOSEJAVIER (JOSE JAVIER)
Subject: Re: [dispatch] [httpstreaming] Q-HTTP

Mike

I'm not sure what you consider to be the primary model and what is the
alternative.  Just in case we don't understand each other, I'll lay out
where I think we are.

At the moment, we don't have QoS management, and HTTP streaming uses
HTTP, which rests on TCP.  Applications don't "degrade themselves", they
get degraded when contention happens, as a result of TCP's flow
management, and have to cope.  It's a 'fair' system in that respect
(especially when contrasted with RTP blast-and-hope).

In a QoS-managed scenario, something 'allows' me to indicate that a flow
'deserves' or 'needs' a certain QoS, including bandwidth, and then (if
granted) I become immune to cross-traffic.  

For example, if all flows are equal, and initially there were 5 of which
2 are QoS managed, and they request only 10% of the resource, we're in
great shape;  they get 20% and the 3 remaining share the remainder 60%,
for 20% each.  But now 7 new flows come along, not QoS managed, so there
are now 10 flows sharing that 60% for only 6% each, while the
QoS-managed ones get 10% -- no longer fair.  If there isn't some
disincentive to QoS-book bandwidth (like having to pay) we'll all set up
the biggest channels we can.  If we *do* have to pay, the complexity of
the QoS management is now increased -- not only handling the technical
booking and reservation, segregation of packet flows, and so on, but it
has a billing infrastructure too.

Then, in the case of QoS management, the service is probably only as
strong as its weakest link.  Some QoS management protocols either set up
an end-to-end QoS-managed flow (across potentially multiple providers)
or they fail.  This doesn't allow for easy service introduction.
Alternatively, they manage only some of the links, and then the
QoS-booking becomes rather weak if the unmanaged link is the bottleneck.

Then there is the question of who sets up and who pays.  Imagine I (in
california) try to watch a BBC video (from the UK).  It's me that needs
to pay, but the BBC that needs to indicate to the service what pipe and
QoS are needed to deliver their content.  Then all the business between
me and them need to work out if they can do that QoS, and at what cost;
someone needs to ask me if I am willing to pay, and if I agree, tell the
BBC to setup the pipe, and off we go.  Contrast this with today where
the BBC is careful not to use too much of its outbound pipe for one
customer, and I buy the pipe I want, and each organization in the middle
sells 'uplink' bandwidth.  That's a 'static' business arrangement.

On Nov 10, 2010, at 17:07 , Mike Hammer (hmmr) wrote:

> My problem is that the alternative solution proposes that:
> 
> 1) Users will police themselves and degrade their experience for the
> good of the Internet, and
> 2) Somehow high-BW bursty applications will become non-bursty.
> 3) The people that build and operate the networks will double
> (quadruple?) their investments for no additional return out of the
> goodness of their hearts.
> 
> Somehow this reminds me of Gates prognostication that 640K was all the
> memory that a PC would ever need.
> 
> I'm sympathetic with having a simple answer, but I just haven't seen
> that happen in the last 30 years.
> 
> Don't forget that for some time we have had QoS managed and paid for.

> The burden of proof then lies in proving the new economic model works.
> Good luck.  I will be the first to congratulate you if you do.
> 
> Cheers,
> Mike
> 
> 
> -----Original Message-----
> From: David Singer [mailto:[e-mail]] 
> Sent: Wednesday, November 10, 2010 10:25 AM
> To: Mike Hammer (hmmr)
> Cc: Mark Watson; Kathy McEwen; [e-mail]; httpstreaming;
> [e-mail]; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA,
> JOSEJAVIER (JOSE JAVIER)
> Subject: Re: [dispatch] [httpstreaming] Q-HTTP
> 
> 
> On Nov 10, 2010, at 16:05 , Mike Hammer (hmmr) wrote:
> 
>> Nice theory.  Until it gets down to who is going to pay for the
>> over-provisioning.
> 
> Well, it's a nice theory until someone asks who is going to (a) pay
for
> the QoS management infrastructure and (b) pay for the QoS managed
> traffic.
> 
>> 
>> 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: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Mark Watson
>> Sent: Tuesday, November 09, 2010 11:19 PM
>> To: Kathy McEwen
>> Cc: [e-mail]; httpstreaming; [e-mail]; 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"
>> <[e-mail]> 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: [e-mail]
>> [mailto:[e-mail]]
>>> 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; [e-mail]; [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/httpstreaming
>>> 
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 

David Singer
Multimedia and Software Standards, Apple Inc.