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

Q-HTTP is not only about testing. If you read that in detail, it has also the messages to alert when something is out of the line. And it also alerts (optionally) a third entity (besides user and SP) to react.

As we implemented this on the lab, we have an external policy manager that received this alert message, and by means of a policy change make the network in between to consider that specific flow or flows (as described in the alert message) to be treated in the same forwarding class as Broadcast TV. Everything keeps at best effort until congestion happens. Then, Q-HTTP alerts of SLA violation and this policy manager changes user profile. Real-Time flow (a virtualized game) keeps just playing with no problem (1 second of freeze) while other user (non-Q-HTTP) can't simply play, the game is just crazy (character is not moving or not stopping).

This was SIMPLE because it was based in the tools we already have in play in some ISPs (lab was based on a real-field network from a big ISP in Spain, with ADSL, aggregation, edge and core network). Simplicity is not measured by the number of pages ;). Of course, this is just a POSSIBLE implementation, not the only one.

And testing is just a MUST. We need to know what is going wrong for THAT flow, because not all the applications/flows have the same requirements.

And yes, i also think that Q-HTTP is not a good name :D

    Saludos,
         Luismi

-----Mensaje original-----
De: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] En nombre de Mikael Abrahamsson
Enviado el: viernes, 12 de noviembre de 2010 4:55
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP

On Fri, 12 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote:

> 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

Yes, but the ARPU doesn't go down because traffic increases, it goes down due to competition and increased market penetration.

> Each year, a little, but the investments in network must increase to support the traffic growing.

Yes. That means profit is down.

> 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.

Prioritization on the access line is good. Prioritization done because you want to flatline your distribution/core at peak times is bad.

> 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.

With hot potato routing, high latency to other countries depend on either bad network design or physical constraints when it comes to speed of light in fiber. QoS can't solve neither.

> 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.

Hard-core gamers won't accept 50ms of keypress/action delay.

> 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.

I started reading the draft but fell ill after reading it a while. It seems to do a lot of testing. We don't need more testing, we need performance information for existing traffic, not more test traffic.

And yes, Q-HTTP is HORRRIBLE name. And no, it's not KISS. Just the size of the draft and the number of sections says it's not KISS.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch