Re: [httpstreaming] [dispatch] [conex] Q-HTTP

[Mikael Abrahamsson <[e-mail]>]

On Fri, 12 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote:

> [[Luismi]]: There is one only real thing we can trust in: ISP is there 
> because of PROFIT. If there is no profit there will be no investment at

Unfortunately there is no upper bound to the amount of profit to be made, 
so profit doesn't mean more network investment, it just means more profit. 
I thought that was obvious by now?

> helping ISPs to do MORE with the same money, and that will benefit 
> users.

If the network is full, it's full. Discriminating certain applications 
doesn't mean you're doing more, it's just that you're doing different 
things with the same bw. It's not more.

> With Q-HTTP we are also providing the tools to users to "audit" 
> what they are paying for. Users will pay extra money for superb services 
> (we are doing that right now when you pay a World of Warcraft or OnLive 
> subscription) and part of that money will end-up on the ISP. Sharing 
> profit between all the players is definetively a good thing IMHO.

Have you seen the roaming prices for mobile data? That's what you get when 
you abandon the bill-and-keep model.

> [[Luismi]]: The problem is that ISPs promises are just vague. Up to X 
> Mbps, with no delay/jitter guarantees is just fine for a lot of 
> applications. It is just not enough for real-time. Besides, a few 
> seconds congestion (for instance, a fiber goes down and all traffic 
> re-routes by another path that becomes 1.5 to 1 congested) will produce 
> a slow down in "standard" service and a complete melt-down in real-time. 
> THAT's what we want to protect. Real-Time application will obtain higher 
> priority during congestion (thus slowing down even more the standard 
> services) and EVERYTHING will be saved. Standard services will survive 
> with a period of "half-speed" and Real-Time will survive unaffected.

No, the real time service will be saved by sacrificing the other services. 
That's not EVERYTHING.

Also, I don't see why we need Q-HTTP to do this? This can be done today 
with existing features. The only upside I see with Q-HTTP is quality 
reporting, but it needs to be done in a different way.

> [[Luismi]]: Then there are a lot of services that never will fly out on 
> Internet. Take a look on OnLive service. They provide virtualized gaming 
> (play XBOX games on your TV without the console, just with a small 
> set-top-box that receives video and sends keys pressed on the pad) by 
> just bypassing the network and installing PoPs just half mile away from 
> your home. That is not economically optimized as you can imagine thus 
> they are translating that into a very expensive service. Just because 
> network does not provide what they need. With QoS, they can offer a 
> centralized service, with really cheaper deployment, lower the service 
> fee to users (win), making more profit (win) and paying a % of that to 
> ISP (win). If we like win-win, you must love this win-win-win (and even 
> better, ISP will re-invest part of that profit on network).

They can get QoS without Q-HTTP. They just need to make a deal with the 
ISP. Oh wait, they can't because of Net Neutrality restrictions.

Also, how do you plan to handle traffic in the outgoing direction from the 
consumer, normally CPEs don't have AQM, so if the customer is uploading 
photos at the same time as someone else in the household plays this game, 
you're bust anyway.

-- 
Mikael Abrahamsson    email: [e-mail]