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

[Harald Alvestrand <[e-mail]>]

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
> 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
themselves -> // (superfluous word)
>    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.
remove extra "for"
>
>    Four Network Parameters comprises the QoS at application level:
>    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".
>
>    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.
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.
>
>    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)
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".
>
>    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
This seems to clearly indicate that the protocol is not deployable by 
end-nodes only. Is this true?
>    5. Integration into rtcweb inititative as a part of the set of 
> components
>        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.
>
>
>    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
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.
> 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
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch