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

"GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com> Fri, 17 December 2010 07:36 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 764793A68FD; Thu, 16 Dec 2010 23:36:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.68
X-Spam-Level:
X-Spam-Status: No, score=-5.68 tagged_above=-999 required=5 tests=[AWL=0.568, 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 Y2c+U-Ckw3+n; Thu, 16 Dec 2010 23:36:36 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 33D6F3A692E; Thu, 16 Dec 2010 23:36:34 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oBH7Y9be005078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Dec 2010 08:34:10 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 17 Dec 2010 08:34:10 +0100
From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>
To: Janet P Gunn <jgunn6@csc.com>
Date: Fri, 17 Dec 2010 08:34:08 +0100
Thread-Topic: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1
Thread-Index: AcudcDbjga71ljA7TKGze/bTAYH+XgASrP7Q
Message-ID: <3349FECF788C984BB34176D70A51782F183F6946@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <OFB818205E.091BC16F-ON852577FB.007ADF83-852577FB.007B37FE@csc.com>
In-Reply-To: <OFB818205E.091BC16F-ON852577FB.007ADF83-852577FB.007B37FE@csc.com>
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_3349FECF788C984BB34176D70A51782F183F6946FRMRSSXCHMBSB3d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13
X-Mailman-Approved-At: Fri, 17 Dec 2010 06:05:20 -0800
Cc: "pedrochas@dit.upm.es" <pedrochas@dit.upm.es>, "'dispatch@ietf.org'" <dispatch@ietf.org>, "dispatch-bounces@ietf.org" <dispatch-bounces@ietf.org>, "ORTIGA HERRERA, GUADALUPE (GUADALUPE)" <guadalupe.ortiga_herrera@alcatel-lucent.com>, "jquemada@dit.upm.es" <jquemada@dit.upm.es>, "CUBILLO PASTOR, CLARA (CLARA)" <clara.cubillo_pastor@alcatel-lucent.com>, "gabriel@dit.upm.es" <gabriel@dit.upm.es>, "barcenilla@dit.upm.es" <barcenilla@dit.upm.es>, "jsr@dit.upm.es" <jsr@dit.upm.es>, "HERRANZ PABLO, SONIA (SONIA)" <sonia.herranz@alcatel-lucent.com>, "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <luismi.diaz@alcatel-lucent.com>
Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1
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, 17 Dec 2010 07:36:38 -0000

Hi Janet,

This new protocol nature for doing it is out-of-band. It means that it will run
in parallel with the protocol in charge of transport application data .
For example this new protocol could be used in parallel with FTP, HTTP , RTC or whatever.

The new protocol measures the quality ( latency, jitter, packetloss, bandwidth) at the
beggining and if the minimum quality is reached, the application can start asuring
a good experience. During the application timelife, the new protocol measures
continuously the latency, jitter an packetloss and alerts if one or some of these
parameters are below certain threshold ( which depends on the application nature).

Therefore, we propose a protocol compatible with all existing transport ones, to provide a
reliable mechanism for adaptative and QoS profile optimization.

The new protocol uses low resources. Depending on the resources being used, the
responsiveness is different. For example, it can be useful to have a better  responsiveness
 in downlink than uplink, depends on each application. However, in any case is a good point
to consume a low bit rate for this purpose, though there is a trade-off between responsiveness and
used bit-rate

- jose javier

________________________________
De: Janet P Gunn [mailto:jgunn6@csc.com]
Enviado el: jueves, 16 de diciembre de 2010 23:26
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: barcenilla@dit.upm.es; CUBILLO PASTOR, CLARA (CLARA); 'dispatch@ietf.org'; dispatch-bounces@ietf.org; gabriel@dit.upm.es; ORTIGA HERRERA, GUADALUPE (GUADALUPE); jquemada@dit.upm.es; jsr@dit.upm.es; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); pedrochas@dit.upm.es; HERRANZ PABLO, SONIA (SONIA)
Asunto: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1


I am a little bit confused by the combination  of
        1. Protocol design to be used in interactive applications (including
      virtualized videogames,and interative-video applications)
  and
    3. Optimizing for low bit rates (typlically below 2.4 kbps)

I do not know many video games that work effectively at 2.4 kbps.

Am I missing something?

Janet




From:   "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>
To:     "'dispatch@ietf.org'" <dispatch@ietf.org>
Cc:     "pedrochas@dit.upm.es" <pedrochas@dit.upm.es>, "CUBILLO PASTOR,        CLARA \(CLARA\)" <clara.cubillo_pastor@alcatel-lucent.com>, "ORTIGA        HERRERA,        GUADALUPE \(GUADALUPE\)" <guadalupe.ortiga_herrera@alcatel-lucent.com>, "jquemada@dit.upm.es" <jquemada@dit.upm.es>, "HERRANZ PABLO,        SONIA \(SONIA\)" <sonia.herranz@alcatel-lucent.com>, "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>
Date:   12/13/2010 10:56 AM
Subject:        [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 1

________________________________




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