Re: [ippm] R: WGLC for draft-ietf-ippm-explicit-flow-measurements

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Wed, 27 July 2022 06: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 D54CEC13C539 for <ippm@ietfa.amsl.com>; Tue, 26 Jul 2022 23:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.807
X-Spam-Level:
X-Spam-Status: No, score=-6.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3-uRd_jCijY for <ippm@ietfa.amsl.com>; Tue, 26 Jul 2022 23:18:20 -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 47DF3C131947 for <ippm@ietf.org>; Tue, 26 Jul 2022 23:18:19 -0700 (PDT)
Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Lt3SW66NPz67vYh; Wed, 27 Jul 2022 14:16:11 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 27 Jul 2022 08:18:16 +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.2375.024; Wed, 27 Jul 2022 08:18:16 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: "Lubashev, Igor" <ilubashe=40akamai.com@dmarc.ietf.org>, Marcus Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org>, Cociglio Mauro <mauro.cociglio@telecomitalia.it>
CC: IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] R: WGLC for draft-ietf-ippm-explicit-flow-measurements
Thread-Index: AQHYoNmdoUDDgk7UAUmiI6NFQeMj7K2Q7AqAgAAGegCAACmLgIAAZpuw
Date: Wed, 27 Jul 2022 06:18:16 +0000
Message-ID: <4820672294e74e918efc3109151d7139@huawei.com>
References: <A3585914-9C69-4428-B867-688FA52D1CC5@apple.com> <AM0PR07MB4131706BB9A9FF78DE62C420E2959@AM0PR07MB4131.eurprd07.prod.outlook.com> <AM7PR07MB6724E67189050D7CE0915C2CE9949@AM7PR07MB6724.eurprd07.prod.outlook.com> <d307f4ebe1574e68b64f716d54b6f6a8@akamai.com> <AM0PR07MB41318ADC08E8A4F5A84DDCFDE2949@AM0PR07MB4131.eurprd07.prod.outlook.com> <909c1f27428943adbd2e00c01f378051@akamai.com>
In-Reply-To: <909c1f27428943adbd2e00c01f378051@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.221.63]
Content-Type: multipart/related; boundary="_004_4820672294e74e918efc3109151d7139huaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/SRHGAg_TOydXSrTxxtDfjG8cOuE>
Subject: Re: [ippm] R: WGLC for draft-ietf-ippm-explicit-flow-measurements
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 27 Jul 2022 06:18:23 -0000

Hi All,
Since the scope of this draft is, as mentioned, to present client-server methods that employ few bits inside the packet header, it is important to remember that the techniques presented can be applicable to different protocols, indeed their description is transport agnostic.
While the application to encrypted transports (e.g. QUIC) is a primary example, these mechanisms can also be useful in other scenarios.
For example, I would point out draft-fz-core-coap-pm that aims to apply spin bit and square bit methods to constrained environments (i.e. CoAP), where simple methodologies for network diagnostic are well suited to the limited resources of constrained nodes requiring just a minimal amount of collaboration from the endpoints.

Regards,

Giuseppe


From: ippm <ippm-bounces@ietf.org> On Behalf Of Lubashev, Igor
Sent: Wednesday, July 27, 2022 12:33 AM
To: Marcus Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org>rg>; Cociglio Mauro <mauro.cociglio@telecomitalia.it>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] R: WGLC for draft-ietf-ippm-explicit-flow-measurements

On reflection, I will agree here with Markus. While the most vocal -- and prolific, in terms of blogs and publications -- supporters of the spin bit had been the researchers, the industry was certainly involved as well.  It is also clear that the owners of the endpoint stacks are currently unconvinced of the value of the spin bit for the Internet ecosystem.

An important goal of this explicit measurements draft is to present other measurements that are possible with just a handful of bits to the industry.  If the industry is particularly interested in some new measurement, stack maintainers may be willing to implement and enable that measurement under certain circumstances.


  *   Igor

From: Marcus Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org<mailto:marcus.ihlar=40ericsson.com@dmarc.ietf.org>>
Sent: Tuesday, July 26, 2022 4:04 PM
(chair hat still off)

I agree somewhat with Igor here, it’s probably more about a lack of interest rather than perceived privacy properties. However, I do not agree that the spinbit was designed purely for research. There was and is industry interest, but perhaps not so much from the part of the industry that build and deploy the endpoint stacks.

From: Lubashev, Igor <ilubashe=40akamai.com@dmarc.ietf.org<mailto:ilubashe=40akamai.com@dmarc.ietf.org>>
Sent: Tuesday, 26 July 2022 15:41
To: Cociglio Mauro <mauro.cociglio@telecomitalia.it<mailto:mauro.cociglio@telecomitalia.it>>; Marcus Ihlar <marcus.ihlar@ericsson.com<mailto:marcus.ihlar@ericsson.com>>
Cc: Tommy Pauly <tpauly@apple.com<mailto:tpauly@apple.com>>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: RE: [ippm] R: WGLC for draft-ietf-ippm-explicit-flow-measurements

It is a very interesting question why spin bit has not received a wider adoption, and whether it is related to its perceived privacy properties.  It is also possible that there is just not enough interest from the industry.  The spin bit was designed by researchers for research purposes.  Loss bits have a significant engagement from the industry.


  *   Igor

From: Cociglio Mauro <mauro.cociglio=40telecomitalia.it@dmarc.ietf.org<mailto:mauro.cociglio=40telecomitalia.it@dmarc.ietf.org>>
Sent: Tuesday, July 26, 2022 6:21 AM
Hi Marcus,
thanks for your interesting suggestions that allow me to explain better Explicit Measurement draft background.
The important thing for us is to recover visibility on performance even using the new QUIC protocol. Explicit measures, if present in all implementations, could achieve this important result. In this way, the legitimate interests of those who develop the applications would not collide with those of the service providers.
The motivation for the inclusion of the Hidden Delay bit in the draft derives from the poor adoption of the spin bit on the net.
The idea is only to provide one more option if the measurement of the end-to-end RTT was a brake to the Spin bit (or Delay bit) adoption.
Starting from this draft, our intention would be to formulate a proposal to the QUIC WG, and maybe even the Hidden Delay bit could be useful in that context, it's hard to know in advance.
Thanks again.

Mauro




Da: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> Per conto di Marcus Ihlar
Inviato: lunedì 25 luglio 2022 23:03
A: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:tpauly=40apple.com@dmarc.ietf.org>>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
Oggetto: [EXT] Re: [ippm] WGLC for draft-ietf-ippm-explicit-flow-measurements

Hi,
Replying here as an individual without the chair hat on.
I think this is good work and describes different useful mechanisms and how they can be combined.

However, I have some problems with the section describing the “Hidden Delay Bit”.
First of all, the motivation for including it is not that strong in my opinion. When the QUIC wg was working on the spin-bit there was a thorough analysis of potential privacy implications. In particular it was shown that using the RTT for geo-location is very difficult and leads to imprecise results. If there has been more recent work in this space that suggest otherwise I think it’s important that this is clearly mentioned in the draft.

The second issue I have with the hidden delay bit is that it actually doesn’t solve the hypothetical problem of RTT-based geo-location. It is fairly straight forward to measure initial RTT by observing handshake packets see (https://www.ietf.org/archive/id/draft-ietf-quic-manageability-11.html#name-measuring-initial-rtt<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-1be72ccfd6669281&q=1&e=73998ff4-2bae-4ab7-ba16-60ebea1d314c&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-quic-manageability-11.html*2Aname-measuring-initial-rtt__*3BIw*21*21GjvTz_vk*21Q2_0tdUpNityV8-getpja839nWOUqt_Yo3zArfJAkASl70BfKb0HtDWcDua4NMKtRiwabhHmk_NCG6HoJEjrN33GlV6ACQ*24__;JSUlJSUlJSUlJSUlJSUlJQ!!GjvTz_vk!RsHcYbjU73nfptB2x9TVD6-hatCJyKm8YIEFjus-hrRUlzBSfEWX8ZJc0Oi9G4RgrOi0XXUAE4WxTO-4K3sVWbums7kqQg$> for instance). An observer that can collect enough initial RTT samples will have enough information to attempt geo-location. Also, with that minimum RTT knowledge it is trivial for an observer to determine the offset used by the client.

So in summary, I think it’s a useful document that has potential to guide future transport protocol work, but I think the hidden delay bit should be removed from the document before moving it forward unless more solid motivation for it can be provided.

BR
Marcus

From: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> On Behalf Of Tommy Pauly
Sent: Wednesday, 6 July 2022 12:04
To: IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: [ippm] WGLC for draft-ietf-ippm-explicit-flow-measurements

Hello IPPM,

This email starts a Working Group Last Call for draft-ietf-ippm-explicit-flow-measurements. This informational document describes various techniques for using exposed bits in protocols to participate in measurement, intended as input for protocols that would like to adopt such techniques.

https://datatracker.ietf.org/doc/draft-ietf-ippm-explicit-flow-measurements/<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-1bfe8b24cbf94f2e&q=1&e=73998ff4-2bae-4ab7-ba16-60ebea1d314c&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-ippm-explicit-flow-measurements*2F__*3B*21*21GjvTz_vk*21Q2_0tdUpNityV8-getpja839nWOUqt_Yo3zArfJAkASl70BfKb0HtDWcDua4NMKtRiwabhHmk_NCG6HoJEjrN30Tx8BjgQ*24__;JSUlJSUlJSUlJSUlJSUl!!GjvTz_vk!RsHcYbjU73nfptB2x9TVD6-hatCJyKm8YIEFjus-hrRUlzBSfEWX8ZJc0Oi9G4RgrOi0XXUAE4WxTO-4K3sVWbvrCmbivw$>
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-explicit-flow-measurements-01<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-e2813c42dc387f26&q=1&e=73998ff4-2bae-4ab7-ba16-60ebea1d314c&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-ippm-explicit-flow-measurements-01__*3B*21*21GjvTz_vk*21Q2_0tdUpNityV8-getpja839nWOUqt_Yo3zArfJAkASl70BfKb0HtDWcDua4NMKtRiwabhHmk_NCG6HoJEjrN30ZgMN3vQ*24__;JSUlJSUlJSUlJSUlJSUl!!GjvTz_vk!RsHcYbjU73nfptB2x9TVD6-hatCJyKm8YIEFjus-hrRUlzBSfEWX8ZJc0Oi9G4RgrOi0XXUAE4WxTO-4K3sVWbsrf5X9wA$>

We’ll run this WGLC up until the IETF week, and we can discuss any feedback as necessary at the IETF 114 meeting.

Please review the document and reply to this email with your comments, and if you think this document should proceed, by Monday, July 25.

Best,
Tommy & Marcus

________________________________
[Image removed by sender.]<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-b15f16cc1b998202&q=1&e=73998ff4-2bae-4ab7-ba16-60ebea1d314c&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fon.tim.it*2Fbanner-mail-dip__*3B*21*21GjvTz_vk*21Q2_0tdUpNityV8-getpja839nWOUqt_Yo3zArfJAkASl70BfKb0HtDWcDua4NMKtRiwabhHmk_NCG6HoJEjrN31YKFbGPw*24__;JSUlJSUlJSUlJSUlJQ!!GjvTz_vk!RsHcYbjU73nfptB2x9TVD6-hatCJyKm8YIEFjus-hrRUlzBSfEWX8ZJc0Oi9G4RgrOi0XXUAE4WxTO-4K3sVWbvjcwlqtQ$>

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.