Re: [httpstreaming] [dispatch] Q-HTTP

Hi Mike and all

Q-HTTP uses a separate control flow for measurements, as you mention, and the application could have N flows. 

When Q-HTTP monitor the quality, it monitors at the "QoS level" of the application flows and alert if constraints are being violated.
If the application has other "non quality" flows, these are not in the scope of Q-HTTP.

Q-HTTP is designed to monitor a set of flows simultaneously (in forward and reverse directions) with different constraints and sensitiveness in each direction. The flows are grouped by constraints, so the same Q-HTTP control flow monitor two sets of flows at the same time:

- a set of downstream flows with the same constraints
- a set of upstream flows with the same constraints ( different from downstream constraints)

The constraints in the same Q-HTTP control flow are defined for up and down sepparately, so the same control flow can have different constraints for up and down, and also different responsiveness (different kbps usage by the control flow in up and down)

The underlaying idea is to allow monitor the quality of any application data protocol used ( simple data over UDP or TCP, ftp, rtp, http, propietary, etc etc), in order to be able to provide a universal measurement/alerting mechanism for any communication at application level.

And...when the alert is raised, what to do? Well, there are a lot of options, for example reduce bitrate of app data flows, or limit the functionalies of the application, or the server can invoke a operator QoS service asking for more quality, or invoke a multi-operator entity which acts over the policy servers of the different operators, or also the network itself could be Q-HTTP aware and react by itself when an alert is raised... All these possibilities are open, and not defined in the draft, but all of them are possibilities

- Jose Javier

-----Mensaje original-----
De: Mike Hammer (hmmr) [mailto:hmmr@cisco.com] 
Enviado el: martes, 09 de noviembre de 2010 16:38
Para: David Singer; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: Ingemar Johansson S; httpstreaming; dispatch@ietf.org; conex@ietf.org
Asunto: RE: [dispatch] [httpstreaming] Q-HTTP

David,

Video has much more volume and burstiness than VoIP, so not sure that analogy will hold.  If you cannot be sure to have at least 50% non-latency-sensitive traffic, and maybe more like 70%, then you will not be over-provisioned enough to have the slack available.  And if video is the lion's share of the traffic, then you better hope that most of that is non-interactive.  Else, you need some type of CAC to ensure live video doesn't get disrupted.

Separate question.  Took a quick read and it seems this Q-HTTP is a separate flow rather than embedded attributes in the flow it is attempting to help.  What if there is more than one flow involved?  And how do you keep each control and app associated?

Mike

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of David Singer
Sent: Tuesday, November 09, 2010 5:31 AM
To: GARCIA ARANDA,JOSE JAVIER (JOSE JAVIER)
Cc: Ingemar Johansson S; httpstreaming; dispatch@ietf.org; conex@ietf.org
Subject: Re: [dispatch] [httpstreaming] Q-HTTP

There is a bitter lesson I have learned over the years to do with QoS reservation.

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.

(I worked on real-time scheduling systems as well, and the same applies; it's cheaper to have a processor which is much faster than needed, with a normal scheduler, than to have a just-enough processor with a real-time scheduler).

I know, it 'feels' wrong.

David Singer
Multimedia and Software Standards, Apple Inc.

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