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

"Lubashev, Igor" <> Tue, 26 July 2022 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62792C13CCCA; Tue, 26 Jul 2022 12:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.575
X-Spam-Status: No, score=-7.575 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_REMOTE_IMAGE=0.01, 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 1bmh0Ok3SleK; Tue, 26 Jul 2022 12:41:12 -0700 (PDT)
Received: from ( [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF627C159490; Tue, 26 Jul 2022 12:41:05 -0700 (PDT)
Received: from pps.filterd ( []) by ( with ESMTP id 26QGqnjq014954; Tue, 26 Jul 2022 20:41:03 +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=MDHGu4/WAIBqnLMw93TdrQMGYFmHXe3qSHqR48sJn3E=; b=hXBoUXfEWmAtaGNoFmsqlGxMqWTFnmKC6AaqJl4jRgt+K1/UI9DrXBnQStfTvom2cQeY h/oyzD0e47/v6nF5vJUknQsI7ygZHb4s+LDgABW28mWaXabVSAHoC2La+Wb8Y0pfzFKs Rg9LVYEJr4gn0Sr3sb8Hqt9kHQZBSF/LPf7CmJISckReRE1QSkSIdQomebKAX9TFRqRN WZhN62LBvWbcncfHEu5LCBWB+v5IIFZSfWREKsEhQdf6syWVnrrje6cjsOeuJjr1g4MY k7YjgQNCs4ya5fG2tra7cZTdpjDiuCq9hOq6KqxqPLz5JzQVD6elZAZTGy4+zC1Ff0CB Kg==
Received: from prod-mail-ppoint4 ( [] (may be forged)) by (PPS) with ESMTPS id 3hj988k19k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jul 2022 20:41:03 +0100
Received: from pps.filterd ( []) by ( with ESMTP id 26QJc4SV011546; Tue, 26 Jul 2022 15:41:02 -0400
Received: from ([]) by (PPS) with ESMTPS id 3hgcbv5nq1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jul 2022 15:41:02 -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 14:41:01 -0500
Received: from ([]) by ([]) with mapi id 15.02.1118.009; Tue, 26 Jul 2022 12:41:01 -0700
From: "Lubashev, Igor" <>
To: Cociglio Mauro <>, Marcus Ihlar <>
CC: Tommy Pauly <>, IETF IPPM WG <>
Thread-Topic: [ippm] R: WGLC for draft-ietf-ippm-explicit-flow-measurements
Thread-Index: AQHYoNl1msslZ0csS0u5zHXo/5Uina2QvyUg
Date: Tue, 26 Jul 2022 19:41:01 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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/alternative; boundary="_000_d307f4ebe1574e68b64f716d54b6f6a8akamaicom_"
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_05,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-2207260075
X-Proofpoint-GUID: kOgf58NoZCr-XFrVMVeGM8ZZ54Vj0hdx
X-Proofpoint-ORIG-GUID: kOgf58NoZCr-XFrVMVeGM8ZZ54Vj0hdx
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib: definitions=2022-07-26_05,2022-07-26_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 adultscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 spamscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207260074
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 19:41:16 -0000

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 (<*name-measuring-initial-rtt__;Iw!!GjvTz_vk!Q2_0tdUpNityV8-getpja839nWOUqt_Yo3zArfJAkASl70BfKb0HtDWcDua4NMKtRiwabhHmk_NCG6HoJEjrN33GlV6ACQ$> 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.<;!!GjvTz_vk!Q2_0tdUpNityV8-getpja839nWOUqt_Yo3zArfJAkASl70BfKb0HtDWcDua4NMKtRiwabhHmk_NCG6HoJEjrN30Tx8BjgQ$><;!!GjvTz_vk!Q2_0tdUpNityV8-getpja839nWOUqt_Yo3zArfJAkASl70BfKb0HtDWcDua4NMKtRiwabhHmk_NCG6HoJEjrN30ZgMN3vQ$>

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


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.