Subject: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 2

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Fri, 7 Jan 2011 13:33:01 +0100

hi folks,

that's the version 2 of Q4S charter , after including the received feedback

The  rtcweb inititative involves to identify and find a consensus on a set of components to communicate universally for real-time communications. Inside this approach, Q4S protocol could be part of this set of agreed protocols, and this goal is part of Q4S objectives. This is an additional point to focus, not included in the followin charter, however it is in our aim.

thanks ,

- Jose Javier

Description of Working group
============================

   Problem Statement:

   The QoS over Internet is a hot issue today. Current QoS handling
   mechanisms used in  modern network transport layers (MPLS, RSVP,
   Diffserv,Traffic Engineering) do not provide  themselves a
   QoS-on-demand end-to-end solution and existing adaptative
   solutions based on In-band Control protocols (such as RTCP)
   are very difficult to combine with any other protocols for which
   they have not been designed for.

   Four Network Parameters comprises the QoS at application level:
   Bandwidth, packet-loss, latency and Jitter.

   Interactive-video applications define flows in both directions.
   Different applications require different constraints (in terms of
   latency, jitter, packet loss) in one or both directions and
   different responsiveness. The proposed solution must be an
   effective out-of-band application level protocol capable of
   reacting when any of these constraints are violated. Such protocol
   must trigger adaptive solutions and/or QoS network profile changes.

   A Q4S protocol monitors and sends alerts, which are useful to know when
   those types of solutions should be taken, but it does not assume that
   that the network is not doing deep packet inspection or differential
   treatment of services.

   Currently content providers are only able to provide services based
   on adaptative methods or last-mille deployments which prefer
   dedicated network resources (vs. Internet), and therefore, restricts
   the subscriber population and increases the costs.

   Objetives:

   The goal of this working group is to define a
   QoS application-level  standard protocol optimized for its use over
   the internet that may be widely implemented and easily managed
   by application developers and service providers.

   The core technical considerations for such protocol include, but
   are not necessarily limited to, the following:

   1. Protocol design to be used in interactive applications (including
      virtualized videogames,and interative-video applications)

   2. Ensuring interoperability with all existing transport protocols

   3. Optimize to use low bit rates in the Q4S control flow (typlically
      below 2.4 kbps) in order to produce a minimum disturbance in
      the application flows.

   4. To ensure a feasible practical implementation based on
      policy servers and interoperability between service providers

   Deliverables:

   1. Specification of protocol that meets the requirements in the
      form of an Internet-Draft that defines the negotiation of QoS
      parameters, the measurement process and alert mechanisms.

   2. Dimensioning rules and performance analysis

   3. A set of technical requirements for a practical
      implementation which may include adaptative solutions and/or
      QoS profile modification.

Goals and Milestiones
=====================

 Nov 2010    Submit Internet-Draft as a proposed standard for QoS
             application-level protocol

             Proposed charter for Q4S WG

             Informational document with rules for dimensioning
             and performance analysis

             Specification of architecture document for implementation

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 13 Jan 2011 19:34:52 -0700

First, cool I like it. Second, I don't understand what you are  proposing. 

Do you have any drafts we should read? I assume draft-aranda-dispatch-qhttp-00.txt

Would this protocol allow the applications to say measure bandwidth or would that come from the data traffic? 

When you talk about the measurement and alerts, could you say a bit more in email here about what you mean by that.
 
Thoughts on how this might interact with DiffServ or ECN? 

Would RTP need something new or could it just use RTCP? 

Use cases for this? 

On Dec 13, 2010, at 8:39 AM, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote:

>  
> Hi everybody,
>  
> Here is the charter proposal for Q4S ( Quality for service) WG. This WG will include the achieved works with  "Q-HTTP"
>  
> Thanks for your comments
>  
>  
>    3. Optimizing for low bit rates (typlically below 2.4 kbps)
>  
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Fri, 14 Jan 2011 09:10:31 +0100

Hi Cullen 

Yes, the draft is draft-aranda-dispatch-qhttp-00.txt  . We are working in a "better explained" draft than this one, but for the moment this is the best we have done, and this is the draft we submitted to the dispatch list on 8 Nov 2010.

This protocol allow applications to measure bandwith, latency , jitter and packetloss in two steps:

 - just at the beginning, checking if the network support the requirements for a given application
 - during the application timelife, checking if the network support the requirements and raising alerts if the network violates some constraints

The protocol does not transport video, data, etc. The protocol only measures and send alerts. It is designed to be used in parallel with other protocols which transport application data. For example, a videogame executed remotelly can send video to the user using rtp ( RTP does not need to change) and the user can send action control using http, or something over UDP, etc. In parallel , Q4S will do the surveillance and will alert if network conditions degrade. 

A possible implementation may use the alerts for two different approach:

 - for adaptative mechanisms: ( for example we are developing a videoserver which reduces the compresion time if latency grows). In other cases , for example FTP, may be reduced the number of FTP threads if packetloss alerts or latency alerts are raised, etc.
 - for QoS profile changing mechanisms: trigger request to the ISP, asking for more QoS ( more bw, less latency, more priority...)

The actions are not defined in the draft, are implementation dependant. For example, as you mention, it could interfact with diffserv, if the ISP check the alerts and change on the fly DSCP markings in the access router, also could act over the access node ( DSLAM or CMTS) changing QoS parameters in response to the alerts

Q4S protocol can be used in parallel with any other protoocl ( RTP, FTP, HTTP, etc) without changes for these protocols, because Q4S runs in parallel and provides a functionality useful for all of them, but at the same time, independent of all of them.

Use cases: virtualized videogames ( video generated remotelly) but also any interactive-video application. In general applications which have bandwidth constraints  but also latency  constraints in order to provide a good user experience

Regards & thanks!

- Jose Javier

-----Mensaje original-----
De: Cullen Jennings [mailto:[email-masked]] Enviado el: viernes, 14 de enero de 2011 3:35
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: [email-masked]'; [email-masked]; CUBILLO PASTOR, CLARA (CLARA); ORTIGA HERRERA, GUADALUPE (GUADALUPE); [email-masked]; HERRANZ PABLO, SONIA (SONIA); [email-masked]; [email-masked]; [email-masked]; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
Asunto: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1

 

Use cases for this?

---

From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <[email-masked]>
Date: Fri, 14 Jan 2011 11:37:35 +0100

Few comments in-line :) 

    Saludos,
         Luismi

-----Mensaje original-----
De: Cullen Jennings [mailto:[email-masked]] 
Enviado el: viernes, 14 de enero de 2011 3:35
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: [email-masked]'; [email-masked]; CUBILLO PASTOR, CLARA (CLARA); ORTIGA HERRERA, GUADALUPE (GUADALUPE); [email-masked]; HERRANZ PABLO, SONIA (SONIA); [email-masked]; [email-masked]; [email-masked]; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
Asunto: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1

[[Luismi]] Correct. We are working in a PPT to explain it in a nutshell anyway :).

[[Luismi]] This protocol will measure by itself and will carry inside all SLAs (delay, jitter, loss) for ALL flows involved in an application (e.g. a videogame that has different flows for video/audio, keyboard commands, voice/video chat, and so on). Just one measurement flow will control all SLAs in a bundle, allowing a superior instance to detect (and react) in case SLA violation.

[[Luismi]] Correct, alert messages (SLA violations) can be sent/copied to a different third entity (beyond application client/server) that can react to the problem by influencing Diffserv DSCP for that SLA-violated flows.

[[Luismi]] This works aside from RTP/RTCP as it is intended to be used with any type of application, but we can think ahead in some kind of interaction with RTP/RTCP if it is worth!! :)

Use cases for this? 

[[Luismi]] Main target is any kind of real-time application with heavy SLA requirements, like video-gaming (clasical and virtualized gaming as in "On-Live"), video-conferencing, tele-medicine, and so. This can be also useful to protect applications that are not RT but are critical in terms of packet loss, like FTP download of critical data, online banking and e-buying.

---

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Tue, 25 Jan 2011 17:41:28 +0100

Hi folks,

we have submitted the Internet Draft "Q4S" protocol, formerly named "Q-HTTP". This version has been achieved as part of Q4S charter proposal (v2) goals and it has been improved  taking into account all received comments, as well as new & fresh co-author's contributions from Univ. Politecnica de Madrid

http://www.ietf.org/id/draft-aranda-dispatch-q4s-00.txt

http://www.ietf.org/id/draft-aranda-dispatch-q4s-00.pdf

Thanks for your comments

-Jose Javier