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