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

Few comments in-line :) 

    Saludos,
         Luismi

-----Mensaje original-----
De: Cullen Jennings [mailto:fluffy@cisco.com] 
Enviado el: viernes, 14 de enero de 2011 3:35
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: 'dispatch@ietf.org'; pedrochas@dit.upm.es; CUBILLO PASTOR, CLARA (CLARA); ORTIGA HERRERA, GUADALUPE (GUADALUPE); jquemada@dit.upm.es; HERRANZ PABLO, SONIA (SONIA); gabriel@dit.upm.es; barcenilla@dit.upm.es; jsr@dit.upm.es; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
Asunto: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1

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

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

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

[[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.

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? 

[[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.

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

[[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.

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
>  
>  
> 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.
>  
>    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. Optimizing for low bit rates (typlically below 2.4 kbps)
>  
>    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
>  
>  
>  
>  
>  
>  
> - Jose Javier
>  
>  
>  
>  
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch