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

["GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[e-mail]>]

Mikael,

Since several years ago, ARPU is frozen and even it has been reduced a little. But traffic grows each year, and as you say, profit goes down. I have check ARPU from Spanish operators and they are reduced
Each year, a little, but the investments in network must increase to support the traffic growing.

An operator can do much more than micropayments and location. Can provide location, presence, availability status, geofencing functionalities, profiling, security based on attack patterns and virus signatures, child protection navigation, unified communications like integration voicemail to social networks, QoS (based on priorization, reservation, traffic mode at access nodes, traffic engineering, path computation) , storage, Content delivery network services, IPTV and IPTV based services, advertising, interactive advertising over IPTV, security, billing, wallet services for micropayments, remote call control, click to dial services, application store services, exposure of messaging services ( MMS, SMS), instant messaging services.....


Priorization reduce queue times, with network full or not. For example, IPTV services offered by operators uses priorization. But do not reduce QoS to priorization. There are more operations involved in QoS.


Regarding latency, it is possible reduce the latency using different operations over the network elements, such as changing traffic mode, choose a good path, priorization and so on. With around 50ms it is possible play a lot of virtualized games. Depending on the required latency, the application can work with a good user experience. But this is not only applicable to virtualized games, but also to traditional online gaming, in which latencies sometimes makes not possible to play against users located in other countries, and in that case constraints are not very restricted , however without QoS, they are impossible to achieve today. 

Hard-core gamers have a high willingness to pay for virtualized games, but today content providers can not offer virtualized games because there is not QoS on demand in Internet.

Have you read the draft? I promise you that Q-HTTP perhaps has an horrible name, but it is KISS, for sure. It is application level, and Q-HTTP alerts can be used for a lot of possibilities from  adapting mechanisms ( reduce bitrate or functionalities)  to priorization , reservation, or whatever. It is not said what to do with the alerts in the draft. It is only a powerful tool.


- Jose Javier


-----Mensaje original-----
De: Mikael Abrahamsson [mailto:[e-mail]] 
Enviado el: jueves, 11 de noviembre de 2010 21:44
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: [e-mail]; httpstreaming; [e-mail]; Mike Hammer (hmmr); Ingemar Johansson S; Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
Asunto: RE: [dispatch] [conex] [httpstreaming] Q-HTTP

On Thu, 11 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote:

> Service providers are worried about ARPU. It is decreasing becasue the 
> "exaflood" phenomenon. The exponential traffic can not be sustained by 
> the network, with incremental increases in bandwidth.

I don't get it. Are you saying that because there is more traffic, the user is paying less money per month? Yes, profit per customer might be down, but why should traffic volume decrease revenue?

> These ISP capabilities can be priced to developers/content providers, 
> increasing ISP revenues. Capabilities such as location, presence, billing, security, QoS....

I agree that an ISP can be a micropayment provider and also provice some location information.

> One of the most important is QoS. If developers can not find 
> profitable business Models, innovation is compromised. QoS means a mix 
> of traffic engineering + priorization + etc

Packet prioritization is only of value when the network is full. QoS is only of interest when BE works badly.

> Now imagine an ISP which offer "intelligent" QoS ( based on Q-HTTP) to 
> enable virtualization of games (like www.onlive.com, but using the 
> network instead locating servers at last mille)

I don't get this either. You can't play an FPS with tens of milliseconds of network delay, so you need to locate servers close to the customers to keep latency low, plus you also don't want the access latency to eat up your latency budget so ADSL and cable goes out the window anyway, the only thing left is the sub-millisecond latency of ETTH.

Btw, I think Q-HTTP is a horrible idea. It seems require a lot of state in the network. State is expensive. What happened to KISS principle?

-- 
Mikael Abrahamsson    email: [e-mail]