Re: [httpstreaming] [dispatch] Q-HTTP

Hi,
   Just my 2 cents on this...

    At the moment, some services are just not flying because of this "fairness" on Internet...My personal opinion is that this is going to end (just hear the loud voices of Network operators like Telefonica claiming that Google needs to pay them for the service they provide). With this in mind, we must assume that the end-customer will pay for such "new-age" services (Google VoD, Online Gaming, Virtualized Gaming or something we cant even think about) to the service provider (Google, Game provider...). This service provider will pay network operator to provide the service to the end user with a minimum quality of experience (this is inline with network operators thoughts). Thus, Tier-1 providers will need to evolve their model from a "per-bit" schema to a "per-bit-per-QoS" one. With all this in mind, we need the tools to:

- Provide the flow requirements. Not all the services require the same parameters from the network
- A way to measure those parameters e2e.
- A way to "cry for help" if those parameters are below (or critically close) the limits
- A way to account for this. You ask for QoS, you pay for that. Once we forget fairness, we forget the flat-rate and change it to "pay for experience".

    Q-HTTP tries to answer this questions. We know this is not simple as involves many other actions (billing, modifying network QoS, multi-tier agreements, etc) but lets start work it out now :).

    Saludos,
         Luismi

-----Mensaje original-----
De: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] En nombre de David Singer
Enviado el: miércoles, 10 de noviembre de 2010 17:27
Para: Mike Hammer (hmmr)
CC: dispatch@ietf.org; Kathy McEwen; httpstreaming; conex@ietf.org; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
Asunto: 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:singer@apple.com]
> Sent: Wednesday, November 10, 2010 10:25 AM
> To: Mike Hammer (hmmr)
> Cc: Mark Watson; Kathy McEwen; dispatch@ietf.org; httpstreaming; 
> conex@ietf.org; 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: 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
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 

David Singer
Multimedia and Software Standards, Apple Inc.

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