Re: [tcmtf] Multiplexing period as a metric
"Jose Saldana" <jsaldana@unizar.es> Mon, 27 May 2013 11:31 UTC
Return-Path: <jsaldana@unizar.es>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id 4CD5521F8AEA for <tcmtf@ietfa.amsl.com>;
Mon, 27 May 2013 04:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.336
X-Spam-Level:
X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=-0.038,
BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3,
RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5XwnYvX1noE for
<tcmtf@ietfa.amsl.com>; Mon, 27 May 2013 04:31:00 -0700 (PDT)
Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by
ietfa.amsl.com (Postfix) with ESMTP id 9D3ED21F8FB6 for <tcmtf@ietf.org>;
Mon, 27 May 2013 04:30:59 -0700 (PDT)
Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by
huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r4RBUpgC031485;
Mon, 27 May 2013 13:30:51 +0200
From: "Jose Saldana" <jsaldana@unizar.es>
To: "=?iso-8859-2?Q?'Mirko_Su=BEnjevi=E6'?=" <Mirko.Suznjevic@fer.hr>,
<tcmtf@ietf.org>
References: <E004A7C54DE04F4BB87DB9F32308DA5C01DE2B@MAIL4.fer.hr>
In-Reply-To: <E004A7C54DE04F4BB87DB9F32308DA5C01DE2B@MAIL4.fer.hr>
Date: Mon, 27 May 2013 13:30:57 +0200
Organization: Universidad de Zaragoza
Message-ID: <00e901ce5acd$a85177f0$f8f467d0$@unizar.es>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00EA_01CE5ADE.6BDB0B40"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGLuLI8sTZIOejSJDehyWlbkLfgWpmeJzVQ
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc: "'Benoit Claise \(bclaise\)'" <bclaise@cisco.com>,
"'Fred Baker \(fred\)'" <fred@cisco.com>, alan.d.clark@telchemy.com
Subject: Re: [tcmtf] Multiplexing period as a metric
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: jsaldana@unizar.es
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion
list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>,
<mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>,
<mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 May 2013 11:31:05 -0000
Just another Idea I had while reading RFC 6390. If you have a look to "5.2. Definitions of a Performance Metric", you can see that metrics can be defined as the composition of different metrics which can be obtained from the network. The idea is: it is clear that VoIP quality depends on Delay and Packet loss. In fact, the MOS depends on that. However, online games react differently to delay, packet loss and jitter. For example, Quake III works perfectly with 35% packet loss, whereas Halo stops working with 4% packet loss (1). And (2) talked about defining different weights for calculating the MOS from delay, jitter and loss. Perhaps we could consider the possibility of having an idea of the service (game) we are multiplexing, and having some heuristics of the influence of delay and jitter in order to select an appropriate multiplexing value. Well, I don't know if this falls within the scope of the current draft, but we could keep it in mind. Thanks! Jose (1) S. Zander, G. Armitage, "Empirically Measuring the QoS Sensitivity of Interactive Online Game Players". In Proc. Australian Telecommunications Networks & Applications Conference (ATNAC 2004), Sydney, Australia, Dec. 2004. (2) Ubicom White Paper, "OPScore, or Online Playability Score: A Metric for Playability of Online Games with Network Impairments", 2005, http://www.kevingee.biz/wp-content/uploads/2011/04/IP3K-DWPOPSCORE-10.pdf De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Mirko Sužnjevic Enviado el: sábado, 25 de mayo de 2013 10:51 Para: tcmtf@ietf.org Asunto: [tcmtf] Multiplexing period as a metric Hello everybody, I have a question regarding the Multiplexing period we mention in our proposal. Should we define it firmly as a metric, as instructed in the RFC 6390 Guidelines for Considering New Performance Metric Development? Could this period be considered as a full metric? For me the most interesting questing in RFC 6390 is: (i) the degree to which its absence would cause significant loss of information on the behavior or performance of the application or system being measured I think that apsence of this metric does limit our information about system performance. Again Multiplexing period as such now is only defined by its limit. Also, it would be dependent on the employed techniques for particular network path and so on. Do you think there is a need to define this as a metric? Thanks for the advices. Best regards, Mirko Suznjevic
- [tcmtf] Multiplexing period as a metric Mirko Sužnjević
- Re: [tcmtf] Multiplexing period as a metric Jose Saldana
- Re: [tcmtf] Multiplexing period as a metric Jose Saldana
- Re: [tcmtf] Multiplexing period as a metric Jose Saldana