Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 4
"GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com> Fri, 04 February 2011 07:40 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 40D993A6886 for <dispatch@core3.amsl.com>; Thu, 3 Feb 2011 23:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.809
X-Spam-Level:
X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[AWL=0.439, 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 3A6lsd0S70O2 for <dispatch@core3.amsl.com>; Thu, 3 Feb 2011 23:40:49 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id A80943A6882 for <dispatch@ietf.org>; Thu, 3 Feb 2011 23:40:47 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p147i70h026195 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Feb 2011 08:44:10 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 4 Feb 2011 08:44:08 +0100
From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <jose_javier.garcia_aranda@alcatel-lucent.com>
To: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 04 Feb 2011 08:44:06 +0100
Thread-Topic: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 4
Thread-Index: AcvEBkHbkL8EPdDjSFaj432KnMMFGgAM2l0w
Message-ID: <3349FECF788C984BB34176D70A51782F1882C99A@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4D0F5BD8.4040506@alvestrand.no> <3349FECF788C984BB34176D70A51782F1882C802@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4D4B4E85.5090907@alvestrand.no>
In-Reply-To: <4D4B4E85.5090907@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_3349FECF788C984BB34176D70A51782F1882C99AFRMRSSXCHMBSB3d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13
Cc: "'dispatch@ietf.org'" <dispatch@ietf.org>
Subject: Re: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 4
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, 04 Feb 2011 07:40:51 -0000
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 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 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. 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. 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 The core technical considerations for such protocol include, but are not necessarily limited to, the following: 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 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. Q4S should be useful for applications using the protocols defined by the rtcweb initiative. 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 ( Standard-track) Feb 2011 Proposed charter for Q4S WG 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
- [dispatch] Charter proposal for Q4S WG ( formerly… GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [dispatch] Charter proposal for Q4S WG ( form… Janet P Gunn
- Re: [dispatch] Charter proposal for Q4S WG ( form… GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [dispatch] Charter proposal for Q4S WG ( form… DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- Re: [dispatch] Charter proposal for Q4S WG ( form… Peter Musgrave
- Re: [dispatch] Charter proposal for Q4S WG ( form… Janet P Gunn
- Re: [dispatch] Charter proposal for Q4S WG ( form… GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [dispatch] Charter proposal for Q4S WG ( form… Harald Alvestrand
- Re: [dispatch] Charter proposal for Q4S WG ( form… GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- [dispatch] Charter proposal for Q4S WG ( formerly… GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [dispatch] Charter proposal for Q4S WG ( form… Cullen Jennings
- Re: [dispatch] Charter proposal for Q4S WG ( form… GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [dispatch] Charter proposal for Q4S WG ( form… DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
- [dispatch] Q4S Protocol ( formerly Q-HTTP) GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- [dispatch] Charter proposal for Q4S WG ( formerly… GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [dispatch] Charter proposal for Q4S WG ( form… Harald Alvestrand
- Re: [dispatch] Charter proposal for Q4S WG ( form… GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
- Re: [dispatch] Charter proposal for Q4S WG ( form… Harald Alvestrand