Re: [httpstreaming] [dispatch] Q-HTTP

Hi

I see ConEx as both a stick and carrot.
The "stick" part because it makes it possible or an operator to make sure that individual users (or groups of users) don't exceed their allowed contribution to congestion (a.k.a congestion volume). 
The "carrot" part is a consequence of the "stick" part, excessive congestion can be avoided in the networks and this means that users runs a much lower risk of experiencing high delay.

Sure you may not get the exact delay you ask for. Possibly ConEx can allow for a lightweight QoS at its best (for instance users pay extra for an extra congestion volume allowance) but perhaps a lightweight QoS is good enough ?
And... I am not convinced that full-fledged QoS gives you the delay you ask for, perhaps on longer timescales this is true. 

I am not pretending that ConEx will solve any problem in the world, there are definitely issues with ConEx and likely some data collection is needed before congestion volume policers and incentive droppers can be tuned in for a good performance, and in addition the endpoints need to be ConEx enabled.

Regards
Ingemar

> -----Original Message-----
> From: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) 
> [mailto:jose_javier.garcia_aranda@alcatel-lucent.com] 
> Sent: den 9 november 2010 18:17
> To: Ingemar Johansson S; Qin Wu; dispatch@ietf.org
> Cc: httpstreaming; conex@ietf.org
> Subject: RE: [httpstreaming] [dispatch] Q-HTTP
> 
> 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 [mailto:ingemar.s.johansson@ericsson.com]
> Enviado el: martes, 09 de noviembre de 2010 4:35
> Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Qin Wu; 
> dispatch@ietf.org
> CC: httpstreaming; conex@ietf.org
> Asunto: RE: [httpstreaming] [dispatch] Q-HTTP
> 
> Hi
> 
> 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 
> (http://tools.ietf.org/wg/conex/charters). 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)
> 
> Regads
> /Ingemar
> 
>  
> 
>   
> 
> > -----Original Message-----
> > From: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) 
> > [mailto:jose_javier.garcia_aranda@alcatel-lucent.com]
> > Sent: den 9 november 2010 00:33
> > To: Qin Wu; dispatch@ietf.org
> > Cc: httpstreaming
> > Subject: Re: [httpstreaming] [dispatch] Q-HTTP
> > 
> > Hi Qin and all,
> > 
> > Now the Q-HTTP draft is accesible at
> > 
> > http://www.ietf.org/id/draft-aranda-dispatch-qhttp-00.txt
> > 
> > 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 [mailto:sunseawq@huawei.com] Enviado el: lunes, 08 de 
> > noviembre de 2010 15:35
> > Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); dispatch@ietf.org
> > 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:
> > http://www.ietf.org/mail-archive/web/httpstreaming/current/mai
> > llist.html
> > 
> > Regards!
> > -Qin
> > ----- Original Message -----
> > From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" 
> > <jose_javier.garcia_aranda@alcatel-lucent.com>
> > To: <dispatch@ietf.org>
> > 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
> > > dispatch@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > >
> > 