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

"Lubashev, Igor" <> Tue, 26 July 2022 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBA7BC13CCF9; Tue, 26 Jul 2022 15:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.585
X-Spam-Status: No, score=-7.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lj0UHEp0RWCy; Tue, 26 Jul 2022 15:33:00 -0700 (PDT)
Received: from ( [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0E75C13CCC4; Tue, 26 Jul 2022 15:32:58 -0700 (PDT)
Received: from pps.filterd ( []) by ( with ESMTP id 26QMKE9P006337; Tue, 26 Jul 2022 23:32:55 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=KBW+eU8C3iV+K494NXT2izaEqLSG4z7RlUxB3KHy5f4=; b=IHx23xVLb+E5cowLSJ6jKjEvVDNT/t059wILyUAZpbyC6QQT5OTU40rkMagKw9r2e53W KsXCzxGlcuypEujhqGhAR6YjCfMrbjD0H/UXrK1KMwhIjXXwUZqZxN9y9qo+4NHB/2i1 N86aOLCnp2A+fsmVi4Rb+V/MAulOR57Tr2scpEV5RCndTdj53rJ3mvj8+9JBGQDWx0cy eEVfkk1kJZPNlyX30Za78z+rXo0V93/D3bX9+XxM88LCO71INuZY1ccfJdSbdQmmohR+ eSykvi8uoHmI4w7NkA/ONg8+wr9tn9dZ93L7UDNqbp5Adp3JbMopcggrTMJnbIpNqM3k MA==
Received: from prod-mail-ppoint4 ( [] (may be forged)) by (PPS) with ESMTPS id 3hjc0fg7ce-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jul 2022 23:32:55 +0100
Received: from pps.filterd ( []) by ( with ESMTP id 26QKhB4T011147; Tue, 26 Jul 2022 18:32:54 -0400
Received: from ([]) by (PPS) with ESMTPS id 3hgcbv6cks-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jul 2022 18:32:54 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Tue, 26 Jul 2022 15:32:53 -0700
Received: from ([]) by ([]) with mapi id 15.02.1118.009; Tue, 26 Jul 2022 15:32:53 -0700
From: "Lubashev, Igor" <>
To: Marcus Ihlar <>, Cociglio Mauro <>
CC: Tommy Pauly <>, IETF IPPM WG <>
Thread-Topic: [ippm] R: WGLC for draft-ietf-ippm-explicit-flow-measurements
Thread-Index: AQHYoNl1msslZ0csS0u5zHXo/5Uina2QvyUggADKQAD//5R3oA==
Date: Tue, 26 Jul 2022 22:32:53 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
msip_labels: MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_Enabled=true; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_SetDate=2022-07-26T10:19:54Z; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_Method=Privileged; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_Name=PUBBLICO; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_SiteId=6815f468-021c-48f2-a6b2-d65c8e979dfb; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_ActionId=41f065bb-37ce-44d7-93d5-bdbdf43bb781; MSIP_Label_d5e397fc-1581-4f20-a09a-f1b2dd53ab2e_ContentBits=0
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_909c1f27428943adbd2e00c01f378051akamaicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib: definitions=2022-07-26_07,2022-07-26_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 suspectscore=0 adultscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207260085
X-Proofpoint-ORIG-GUID: SxBIA5tlrXdU4htuM9gTmZUI7HqZnTu-
X-Proofpoint-GUID: SxBIA5tlrXdU4htuM9gTmZUI7HqZnTu-
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib: definitions=2022-07-26_07,2022-07-26_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 suspectscore=0 spamscore=0 clxscore=1015 impostorscore=0 bulkscore=0 mlxscore=0 adultscore=0 lowpriorityscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207260085
Archived-At: <>
Subject: Re: [ippm] R: WGLC for draft-ietf-ippm-explicit-flow-measurements
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jul 2022 22:33:05 -0000

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 <>
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 <<>>
Sent: Tuesday, 26 July 2022 15:41
To: Cociglio Mauro <<>>; Marcus Ihlar <<>>
Cc: Tommy Pauly <<>>; IETF IPPM WG <<>>
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 <<>>
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.


Da: ippm <<>> Per conto di Marcus Ihlar
Inviato: lunedì 25 luglio 2022 23:03
A: Tommy Pauly <<>>; IETF IPPM WG <<>>
Oggetto: [EXT] Re: [ippm] WGLC for draft-ietf-ippm-explicit-flow-measurements

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 (<*3A*2F**2Fv3*2F__https*3A**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.


From: ippm <<>> On Behalf Of Tommy Pauly
Sent: Wednesday, 6 July 2022 12:04
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.<*3A*2F**2Fv3*2F__https*3A**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$><*3A*2F**2Fv3*2F__https*3A**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.

Tommy & Marcus

[Image removed by sender.]<*3A*2F**2Fv3*2F__https*3A**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.