Re: [ippm] Which bits to use for explicit performance measurements?

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Thu, 29 July 2021 10:18 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05073A1C8C; Thu, 29 Jul 2021 03:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRE5rYi5w0Mc; Thu, 29 Jul 2021 03:17:59 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727A13A1C8D; Thu, 29 Jul 2021 03:17:59 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Gb5lG2y65z6LBnH; Thu, 29 Jul 2021 18:06:02 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 29 Jul 2021 12:17:57 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2176.012; Thu, 29 Jul 2021 12:17:57 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Cociglio Mauro <mauro.cociglio=40telecomitalia.it@dmarc.ietf.org>, "martin.h.duke@gmail.com" <martin.h.duke@gmail.com>, IETF IPPM WG <ippm@ietf.org>
CC: "wehrle@comsys.rwth-aachen.de" <wehrle@comsys.rwth-aachen.de>, "Ike.Kunze@comsys.rwth-aachen.de" <Ike.Kunze@comsys.rwth-aachen.de>, "explicit-meas@ietf.org" <explicit-meas@ietf.org>, Jan Rüth <rueth@comsys.rwth-aachen.de>, "quic@ietf.org" <quic@ietf.org>
Thread-Topic: Which bits to use for explicit performance measurements?
Thread-Index: AdeEVHmu1EyYtIPQQ2qUvt54N6OCEQABk7FA
Date: Thu, 29 Jul 2021 10:17:57 +0000
Message-ID: <39bd43418f3a49538560bb71adf9a8e1@huawei.com>
References: <DBAPR07MB67751235405D608142EB5C27E9EB9@DBAPR07MB6775.eurprd07.prod.outlook.com>
In-Reply-To: <DBAPR07MB67751235405D608142EB5C27E9EB9@DBAPR07MB6775.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.83.0]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Pn-MYWPsoaTQX8zflFfeh-7_Zi0>
Subject: Re: [ippm] Which bits to use for explicit performance measurements?
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jul 2021 10:18:05 -0000

Hi Martin, Mauro, All,
Let me also highlight that draft-mdt-ippm-explicit-flow-measurements is informational and, similarly to the experimental RFC 8321 and RFC 8889, it describes different alternatives for performance measurement. Then, a future standards track specification can pick up the most suitable method.

To address the comment of Martin, I would suggest to add a new final section titled, for instance, "Report on the Operational Experiment and Deployment", where it can be possible to include the current experiments and existing deployments and also give suggestions and guidance for the implementation. In this way, developers can get more information when they read the draft.

Regards,

Giuseppe



-----Original Message-----
From: Explicit-meas <explicit-meas-bounces@ietf.org> On Behalf Of Cociglio Mauro
Sent: Thursday, July 29, 2021 11:01 AM
To: martin.h.duke@gmail.com; IETF IPPM WG <ippm@ietf.org>
Cc: wehrle@comsys.rwth-aachen.de; Ike.Kunze@comsys.rwth-aachen.de; explicit-meas@ietf.org; Jan Rüth <rueth@comsys.rwth-aachen.de>; quic@ietf.org
Subject: [Explicit-meas] Which bits to use for explicit performance measurements?

Hi Martin and All.

I would like to answer your question from yesterday IPPM session in a more detailed way.
If I understood well your question is:
"Which bits, at the end, we suggest to use among all those proposed in the draft for explicit performance measures?"
(https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measurements-02)

Taking for granted that the usable space consists of 3 bits I would say to use 1 bit for RTT and 2 bits for Packet Loss.
Starting from the results of Aachen University ANRW paper (https://arxiv.org/pdf/2106.13710.pdf) we can say that, for Packet Loss, 1 bit is not enough:
. T-bit is not a so accurate measurement.
. Q-bit is not an end-to-end measure.
. L-bit does not allow the localization of the impairment.
So the best proposition, in our opinion, is to use 2 bits.
The 1st is definitely the Q-bit, coupled either with L-bit or with R-bit.
The L-bit is very accurate and works well even with short sessions, but it is a signal of the losses recorded by the protocol, not an independent measure.
If you want a protocol independent measurement you need to use R-bit, which even with some limitations in the case of short sessions (it needs to wait for the completion of a Q period on one side of the connection before reflecting it on the other) has proven to work quite well.

We now come to RTT measurement, considering in particular the QUIC protocol, where there is already a standardized bit, even if not mandatory, on this measure.
The Spin bit, albeit with some limitations in case of impairments (in particular out-of-sequence) and the fact that it "mixes" the application delay with the network delay, has proved to work quite well. The problem is that, up to now, it has not been implemented and in the QUIC traffic on the network it is not present.
It is a question of understanding the reasons for this fact.
If the issue of privacy is the main problem, the proposal of the D-bit, in the version with Hidden RTT, could be considered for the next version of QUIC protocol.

BR.

Mauro

_____________________
Mauro Cociglio
TIM - CI.TIS.IPT
Via G. Reiss Romoli, 274
10148 - Torino (Italy)
Tel.: +390112285028
Mobile: +393357669751
_____________________


TIM - Uso Interno - Tutti i diritti riservati.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

-- 
Explicit-meas mailing list
Explicit-meas@ietf.org
https://www.ietf.org/mailman/listinfo/explicit-meas