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

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Thu, 3 Feb 2011 17:05:31 +0100

hi folks,

that's the version 3 of Q4S charter , after including more received feedback and integration with rtcweb initiative into our objetives

regards

- 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

   5. Integration into rtcweb inititative as a part of the set of components
       used to communicate universally in real-time communications.

   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.

   4. Analysis of benefits of Q4S in real-time internet applications
      and how Q4S complements the rest of components of
      rtcweb initiative

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

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

Jan 2011  Submision of Q4S protocol Internet-Draft as
               improvement of Q-HTTP protocol

Feb 2011  Proposed charter for Q4S WG

             Informational document with rules for dimensioning
             and performance analysis

             Specification of architecture document for implementation

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 03 Feb 2011 16:55:33 -0800

I think the milestones may need some more tuning - as presently 
presented, all the work of the group will be done in February 2011.

What timescale do you anticipate for this work, and who do you think 
will participate (as opposed to who you *want* to participate)?

On 02/03/11 08:05, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote:
> hi folks,
> that's the version 3 of Q4S charter , after including more received 
> feedback and integration with rtcweb initiative into our objetives
> regards
> - jose javier
themselves -> // (superfluous word)
>    they have not been designed for.
remove extra "for"
>    Bandwidth, packet-loss, latency and Jitter.
actually perceived quality is likely to be affected not just by the 
values of these parameters, but by the *changes* in these parameters - 
if available bandwidth suddenly drops, creating dropouts, people are 
going to perceive the quality as worse than the quality of a 
lower-bandwidth channel that's there all the time. I would suggest 
"comprises" -> "are commonly used to measure".
>    by application developers and service providers.
does the protocol require service providers to implement it before it's 
useful? The charter should state whether the goal is a protocol that can 
be deployed by end-nodes, or whether it needs in-the-network help.
>       virtualized videogames,and interative-video applications)
suggest "to be used in" -> "should be useful for"
>    2. Ensuring interoperability with all existing transport protocols
suggest "Q4S should be applicable for measuring quality of connections 
using all existing transport protocols".
>       policy servers and interoperability between service providers
This seems to clearly indicate that the protocol is not deployable by 
end-nodes only. Is this true?
>        used to communicate universally in real-time communications.
Suggest "Q4S should be useful for applications using the protocols 
defined by the rtcweb initiative" - I have no real comprehension of what 
specific action would be required by the existing text.
>       and how Q4S complements the rest of components of
Please fill in the goals and milestones with when you expect to deliver 
the deliverables. Also, indicating which of the items are intended to be 
standards-track woudl be useful.
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Fri, 4 Feb 2011 08:44:06 +0100

first, thanks for your suggestions, i have made changes in the document based on them.

we are working in a two and a half years long project for deploy Q4S in a fixed network and in a mobile (LTE) network.
The initial steps are the definition of the protocol, but after implementation and checking some use cases we will get
some interesting measurements and dimensioning rules in terms of number of users, traffic, number of Q4S
transactions vs number of sessions, etc

The deployment in which we are working now is based on a policy server, which receives the Q4S alerts  and acts
over network elements in real-time to provide a better QoS. If the protocol is only implemented in end-nodes
then the measurements and the alerts can be only used for adaptative mechanisms. However, if a policy server
is able to receive Q4S alerts and send commands to network elements to change QoS profiles ( in terms of
priorities, queue-sizes, bandwidth, resource reservation, path changes, etc) then the Q4S becomes a high
potential tool.

The other possible implementation consists of a "Q4S network aware", in which network elements detects by
themselves the QoS alerts and auto-tune. This implementation needs specific HW and SW to be achieved.

in this new version  i have tuned the milestones in order to be more clear in our commitments, and i have
made the changes according with your right suggestions

Thanks,

- Jose Javier

   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  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.
   Four Network Parameters are commonly used to measure 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.

   Objetives:

   If the protocol is only implemented in end-nodes then the
   measurements and the alerts can be only used for adaptative mechanisms.
   However, if a policy server is able to receive Q4S alerts and send
   commands to network elements to change QoS profiles ( in terms of
   priorities, queue-sizes, bandwidth, resource reservation, path changes, etc)
   then the Q4S becomes a high potential tool for internet real-time applications

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

   2. Q4S should be applicable for measuring quality of connections using
       all existing transport protocols

   5. Q4S should be useful for applications using the protocols
       defined by the rtcweb initiative.

   Deliverables:

Jan 2011  Submision of Q4S protocol Internet-Draft as
               improvement of Q-HTTP protocol ( Standard-track)

Jul 2011   informational document about use-cases and virtualized
               videogames perceived quality under network QoS changes

Jun 2012 Specification of architecture document for implementation
Dic  2012  Informational document with rules for dimensioning
               and performance analysis

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 04 Feb 2011 09:29:50 -0800

Thank you, this makes it much clearer.

         Harald