Re: [httpstreaming] [dispatch] Q-HTTP

"GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <> Tue, 09 November 2010 10:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A371028C18A; Tue, 9 Nov 2010 02:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.191
X-Spam-Status: No, score=-5.191 tagged_above=-999 required=5 tests=[AWL=1.058, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jfMfiYGpeMSA; Tue, 9 Nov 2010 02:17:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E9FFD3A6946; Tue, 9 Nov 2010 02:17:05 -0800 (PST)
Received: from ( []) by (8.14.3/8.14.3/ICT) with ESMTP id oA9AHNgr027255 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 9 Nov 2010 11:17:23 +0100
Received: from ([]) by ([]) with mapi; Tue, 9 Nov 2010 11:17:23 +0100
To: Ingemar Johansson S <>, Qin Wu <>, "" <>
Date: Tue, 9 Nov 2010 11:17:21 +0100
Thread-Topic: [httpstreaming] [dispatch] Q-HTTP
Thread-Index: Act/YysCX7CwpgwoTOi2u5WUtY8rLwAWmcIAAA0pyyA=
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: es-ES
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on
Cc: httpstreaming <>, "" <>
Subject: Re: [httpstreaming] [dispatch] Q-HTTP
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Nov 2010 10:17:07 -0000

Hi Ingemar

Congestion control mechanisms and exposure give operators the way to avoid problems in their networks and also reward users which does not impact on others, but does not cover the need for a quality in terms of latency and jitter, but only packet loss.

The scenario in which a particular user is paying to a content provider to ( for example) play a virtualized game, and the content provider pays to the operator in order to be possible a QoS on demand (during few minutes) for the flows from server to this particular user is the goal of Q-HTTP and although congestion must be measured, the rest of quality parameters are also important and of course the reaction time of the protocol is a key factor.

In this scenario probably this particular user is contributing to the congestion of others but should not be penalized. Conex as a form of fifferential QoS could serve this goal, but needs the help of "something like Q-HTTP" to achieve the measurements. Don't you agree?

In a philosophy perspective, we need these pieces: 
     1) a network with differential QoS capability   ( diffserv, traffic engineering, PCE, traffic mode at access node, etc)
     2) a unified measurement procedure capable to react  ( Q-HTTP ?)
     3) something to match the reactions with the QoS capability of the network ( CONEX ?)

Apart from this, in terms of overhead, Q-HTTP only uses a few Kbps, and it is configurable ( more responsiveness implies more kbps) but for example in our implementation, 15kbps is quite good for measure downstream and 1kbps for measure upstream. The responsiveness is defined at the first stage of the protocol, so can be whatever content provider wants, depending on the type of content.
- Jose Javier

-----Mensaje original-----
De: Ingemar Johansson S [] 
Enviado el: martes, 09 de noviembre de 2010 4:35
CC: httpstreaming;
Asunto: RE: [httpstreaming] [dispatch] Q-HTTP


I have skimmed through the pdf, thanks for posting this. My immediate reaction is that this machanism is trying to react to indicators of congestion in various ways. 

An alternative would actually be ConEx ( With ConEx enabled flows the re-feedback information can be used by both operator and user to verify that a SLA is met.
For instance, if a user is promised a bandwith of 200kbps for his gaming experience and still experience a high congetsion volume, this would be clearly visible for the operator (as well as the user). I don't believe that ConEx has outlined this particular use case but I would say that it should be doable.
ConEx has the benefit that it does not add much extra overhead, there are of course issues with ConEx (as with any other new technology)




> -----Original Message-----
> []
> Sent: den 9 november 2010 00:33
> To: Qin Wu;
> Cc: httpstreaming
> Subject: Re: [httpstreaming] [dispatch] Q-HTTP
> Hi Qin and all,
> Now the Q-HTTP draft is accesible at
> In addition, i have attached in this email a FAQ document for easier 
> understanding of the protocol. This document clarifies the philosophy 
> and shows different alternatives for the implementation
> Regards and thanks
> - Jose javier
> -----Mensaje original-----
> De: Qin Wu [] Enviado el: lunes, 08 de 
> noviembre de 2010 15:35
> CC: httpstreaming
> Asunto: Re: [dispatch] Q-HTTP
> Hi, Joes Javier:
> Your bring a quite interesting draft. We have a Bar BOF on HTTP 
> streaming on Wednesday evening, Emenrald room, which aims at  building 
> new area and working out appropriate working scope to offer more 
> efficient transport and better QoE. One of key issues we are ready to 
> address is QOE improvement. If you are interested, please join our 
> discussion.
> Also you can track the following link for our meeting agenda, location 
> and time:
> llist.html
> Regards!
> -Qin
> ----- Original Message -----
> <>
> To: <>
> Sent: Monday, November 08, 2010 4:14 PM
> Subject: [dispatch] Q-HTTP
> Hi experts,
> We are a group of researchers which have written a draft about QoS 
> measurements & reactions. We believe the standardization of this topic 
> could benefit internet community in the coming years, for example for 
> virtualization of videogames through intenet. We would like to receive 
> comments and some feedback and also oppinions about the target area, 
> because we believe that the draft fits into Real-time App and 
> infrastructure Area scope, but currently the draft is in "looking for 
> an area" state
>    The draft describes Q-HTTP (Quality HTTP) , which is an application 
> level protocol based on HTTP and SDP associated to a new specific uri 
> "httpq://..." intended for carrying out quality negotiation and 
> quality measurement between two parties. The final goal of this 
> process is to verify that a certain application which depends on 
> bandwidth, latency, jitter parameters, will work under current network 
> conditions. Our idea tackles the fact that real-time services 
> (virtualization, on line gaming, video, voice) nowadays are increasing 
> and that in an internet (or WAN) environment propagation conditions 
> may change with time for our connection; what works for most 
> applications may not work for real-time ones and they should have a 
> standard way of negotiating and verifying their requirements. Q-HTTP 
> also provides a mechanism of account/alerting when required 
> constraints are not met after the measurement is carried out.
>  Implementation details on the actions to be triggered upon 
> reception/detection of QoS alerts exchanged by the protocol are out of 
> scope of this draft, it is application dependant (e.g. increase 
> quality, reduce bit-rate) or even network dependant (e.g. change 
> connection's quality profile).
> Comments? Thanks
> - Jose Javier
> --------------------------------------------------------------
> ------------------
> > _______________________________________________
> > dispatch mailing list
> >
> >
> >