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

"GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com> Fri, 07 January 2011 12:35 UTC

Return-Path: <jose_javier.garcia_aranda@alcatel-lucent.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA993A6834 for <dispatch@core3.amsl.com>; Fri, 7 Jan 2011 04:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.694
X-Spam-Level:
X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfByo-ctdSRF for <dispatch@core3.amsl.com>; Fri, 7 Jan 2011 04:35:06 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id AF85C3A682E for <dispatch@ietf.org>; Fri, 7 Jan 2011 04:35:05 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p07CX3ZO016700 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jan 2011 13:33:03 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 7 Jan 2011 13:33:03 +0100
From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>
To: "'dispatch@ietf.org'" <dispatch@ietf.org>
Date: Fri, 07 Jan 2011 13:33:01 +0100
Thread-Topic: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 2
Thread-Index: AcugSvRWsT7gbY+GSyqLnLGU53HqvAAGPezQA4BiV1A=
Message-ID: <3349FECF788C984BB34176D70A51782F18574396@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4D0F5BD8.4040506@alvestrand.no>
Accept-Language: en-US
Content-Language: es-ES
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F18574396FRMRSSXCHMBSB3d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83
Cc: "pedrochas@dit.upm.es" <pedrochas@dit.upm.es>, "CUBILLO PASTOR, CLARA (CLARA)" <clara.cubillo_pastor@alcatel-lucent.com>, "jquemada@dit.upm.es" <jquemada@dit.upm.es>, "gabriel@dit.upm.es" <gabriel@dit.upm.es>, "barcenilla@dit.upm.es" <barcenilla@dit.upm.es>, "jsr@dit.upm.es" <jsr@dit.upm.es>, "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <luismi.diaz@alcatel-lucent.com>
Subject: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 2
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jan 2011 12:35:08 -0000

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