Re: [ippm] [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)

"Bulgarella Fabio (Guest)" <fabio.bulgarella@guest.telecomitalia.it> Thu, 01 April 2021 15:03 UTC

Return-Path: <fabio.bulgarella@guest.telecomitalia.it>
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 F3F5A3A174A for <ippm@ietfa.amsl.com>; Thu, 1 Apr 2021 08:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=guest.telecomitalia.it header.b=Q134Mb/E; dkim=pass (2048-bit key) header.d=guest.telecomitalia.it header.b=hEKKO0kt
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 a79cE0-K5iG7 for <ippm@ietfa.amsl.com>; Thu, 1 Apr 2021 08:03:51 -0700 (PDT)
Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20F63A1787 for <ippm@ietf.org>; Thu, 1 Apr 2021 08:03:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=guest.telecomitalia.it; s=selector1; c=relaxed/relaxed; q=dns/txt; i=@guest.telecomitalia.it; t=1617289415; x=2481203015; h=MIME-Version:From:Date:Message-ID:Subject:To; bh=Ig0yN0ZXJ9UNH2iNfv8Zy8DUX+2hyhaUW6D0XeyDcYU=; b=Q134Mb/EANNUXKt2eUb971vqms9qDlMRdx23kJG9fH2539LmdgBM4lyeqlGd3S5K rBVMKau2XrM5kggCQEav62M4mTlQM4F8QgRQErBuCaGGP69RHqFDrIkicYq/QnQ1 pi4nlMbAXfoaMls39gtnSDJeOLk19S91h+EoTajzHvuEQMDGEQONp5S86BD6+j5z 7vNxt5FJUm5SURxtwmmS3Ia8py3SYHOI/UUewc4VfWD+llliu2bXIo+zIgKzvvo8 KIFqK6lKtaGJqfooLCkTqRWrDusDqouDww+Je+3Z1Ep/4k/RpNK7MJiYE92tq1lg Akpqi8aNDhJ0dpqJfo5/RQ==;
Received: from mx05.telecomitalia.it ( [10.90.45.21]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id 0D.C1.08746.7C0E5606; Thu, 1 Apr 2021 17:03:35 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; d=guest.telecomitalia.it; s=selector1; c=relaxed/relaxed; q=dns/txt; i=@guest.telecomitalia.it; t=1617289414; x=2481203014; h=MIME-Version:From:Date:Message-ID:Subject:To; bh=Ig0yN0ZXJ9UNH2iNfv8Zy8DUX+2hyhaUW6D0XeyDcYU=; b=hEKKO0ktb8mDGMh7ADstwjrt5ucpESIly4Vx8q5FJTaWD6ZkM4yBlqKwiUYBwTDf to1BvxvUSX4TH/ZzS+Z4ACGnqbm8JKBnMCedNeaprRwT/fUA/Etm1o0Zh4LljxG2 YlM2XOAsHYi1QqKVEIa//YjgT1Nd9OWYpBQcD34/zoHV/jSSy+WuuNAHKi2vjGl3 wgHzTQ4ZDUmPdJWn5oePSkEaAXuhJGUcsnsSUsjdZmyq00Ew088Uox7WTMQabnEk poD7x4XFySmWylRnvMU9PRHEnIUjQ1NVLWWGnBuqAPNKdp5eY6oB0bxd6rhZHc5t dtjeyjEu6yZIrFZHlsu3CA==;
X-AuditID: d9a97916-156aa7000000222a-ba-6065e0c701d0
From: "Bulgarella Fabio (Guest)" <fabio.bulgarella@guest.telecomitalia.it>
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "Lubashev, Igor" <ilubashe@akamai.com>
CC: "explicit-meas@ietf.org" <explicit-meas@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, "HAMCHAOUI Isabelle IMT/OLN" <isabelle.hamchaoui@orange.com>, Cociglio Mauro <mauro.cociglio=40telecomitalia.it@dmarc.ietf.org>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>, "quic@ietf.org" <quic@ietf.org>
Thread-Topic: [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)
Thread-Index: AQHXJlZVKloFGJxR10iHzJiSxgzoIaqfdUpu
Date: Thu, 1 Apr 2021 15:03:34 +0000
Message-ID: <1617289414202.66173@guest.telecomitalia.it>
References: <8f60ffc8e0fd4376ba911c03f5c43039@TELMBXD14BA020.telecomitalia.local> <56398ea2e37a4a6ca53e85eb39add9a2@usma1ex-dag1mb5.msg.corp.akamai.com> <CAKcm_gNb-J59S3w806V4h2P_K5TkozRXNJCpNmMHbUcSOVjnUQ@mail.gmail.com> <CAKKJt-dXpDGF79_5HJ1aQanPyJBcPEizvKt4rJBJ2jsNthOaJw@mail.gmail.com> <8332062d02c04f40af1ed3baef49dafc@usma1ex-dag1mb5.msg.corp.akamai.com> <CAKKJt-f5OJdKGXrJPZffTLEd4UhhtfgJWCvXHRpNheVFKN9JjQ@mail.gmail.com>, <5d60e177b8ee477fb6409a4a0d2af81a@huawei.com>
In-Reply-To: <5d60e177b8ee477fb6409a4a0d2af81a@huawei.com>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [45.33.239.140]
Content-Type: multipart/alternative; boundary="_000_161728941420266173guesttelecomitaliait_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsXCFaUrqnv8QWqCwdXXLBY9D94xOzB6LFny kymAMYrLJiU1J7MstUjfLoErY++fA0wFE3czVhxY0cHewDh1G2MXIyeHhICJxMNl35m6GLk4 hAS6mSS2PdnCDOKwCHxikehe08rSxcgOVrXFv4uRg4NNwEti9h1lkAoRgemMEkubbrCDOMwC y5klNi77ADZUWCBTYsXvp2C2iECWxKJZb5ggbCOJG7vPgsVZBFQk7u2+yApi8wpYSFy80s0K ccQzZombjSfZQRKcAlYSTzb/ACtiFJCVmLB7EVgzs4C4xIvpJ9ghPhCQWLLnPDOELSrx8vE/ VgjbQGLr0n0sELaixONJS5gheuMkzj6ZxA6xWFDi5MwnLCCLJQTecEgcbrjMNoFRfBaSHbOQ 9MxC0jMLGBrMApoS63fpQ5QoSkzpfghVriHROmcuO7L4Akb2VYyiuRUGRnolqTmpyfm5mSWJ OZmJepklmxiBEXlzZaXYDsbZG97oHWJk4mA8xCjBwawkwntjS2qCEG9KYmVValF+fFFpTmrx IUZpDhYlcd7qW0ApgfTEktTs1NSC1CKYLBMHp1QD06HcT3L6CzbqGyS+mbV9puydsKi5HyQ1 VKIbN1fv+bp544N39dJP/6VsSr51d5/FhR/251YnxKTzpKgL+n57cnq5QBrv4a+Bf76FMiXG CH+/aCeosCXb281rU6pc9Fv2Ct0wU/+2L28TZFmevPs4xTxU+sBxPYWDhZsWdm+7e0/39ttP 018rJH2dffjxpL2/q3v9jddIdUUs5Jxi8ufXhWd/dyX3Jqzir5i9rNtni8hHH5VV/UpJ+10a Ih9xTkvab/9xi4aSSsVuy/8XmbR2f0iImGkWySSR/thGZc2v33e8xX5kt3V+jzFjNrPs/MbJ OFfG7uLxjYUBj5L5/niVKqZ7WnYdZ5eoelD26+3qs0osxRmJhlrMRcWJAHk6INQ3AwAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsXCFaWtr3vsQWqCwZe1+hbLfshbLNlwltli zZwVTBYPf35ltGhqWMFs0fPgHbPFpYMf2S0W7l3DYtGzgNti2ZQ9zBbH3txlc+D2mHxkAbPH iWVXWD12zrrL7tFy5C2rx5IlP5k8Wp6dZAtgi+KySUnNySxLLdK3S+DK2PvnAFPBxN2MFQdW dLA3ME7dxtjFyM4hIWAiscW/i5GLQ0hgFaPE5o4XLF2MHBxsAl4Ss+8og8RFBKYzSixtusEO 4jALLGeW2LjsA1AvJ4ewQKbEit9PwWwRgSyJRbPeMEHYRhI3dp8Fi7MIqEjc232RFcTmFbCQ uHilmxVi2zNmiZuNJ9lBEpwCVhJPNv8AK2IUkJWYsHsRWDOzgLjEi+knwGokBAQkluw5zwxh i0q8fPyPFcI2kNi6dB8LhK0o8XjSEmaI3jiJs08msUMsFpQ4OfMJywRGkVlIxs5CUjYLSdks YAAwC2hKrN+lD1GiKDGl+yFUuYZE65y57MjiCxjZVzGK5lYYmOqVpOakJufnZpYk5mQm6mWW bGIEx7Wu6A7GbSve6B1iZOJgPMQowcGsJMJ7Y0tqghBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe mltAKYH0xJLU7NTUgtQimCwTB6dUA5PZBc3/TalhJg2NUyoXBz19mVY7fcfaTTXH7E/bf/mp 8M24NLVpy+ord3+/bZ6YpbfoccN5Sz+/k+s7D0ZvMV4R8OtI7K87akEsnk9uzChaX+V/mL/x VmLl8uAfnadmv9g9/4bH3TydSP4dnfNMsoPmzbjT/uPN/FssVj99L8y2Z7/2Z2tKm0938sn3 tzbPN8jclKYq38O3c0N4r7fcst+bDOUXnNl166+HZp+kU1W6ynLN9UYX5W6uk1++lGvuin/z WjUWte7Pk7h52iIkOCxGWX4LU8iPbmHx/xGXz02wOBz6clptAUPTcae9tU6ZtTWHVu7mcc/T CtzDv6nXJ6fp+rGNvtXld4SOqbtuuxKvxFKckWioxVxUnAgACOkLMVoDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/MpiIxjPPihwtimzQZKA9R0rFFJw>
X-Mailman-Approved-At: Mon, 05 Apr 2021 10:42:33 -0700
Subject: Re: [ippm] [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)
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, 01 Apr 2021 15:04:02 -0000

Hi All,​


I agree with Giuseppe that each methodology is different. Some of them expose more information than others.

In any case, to better protect the user's privacy, in draft (https://tools.ietf.org/html/draft-cnbf-ippm-user-devices-explicit-monitoring-01) we propose that users should explicitly authorize the application to use the marking.
If the user does not take a decision, to further strengthen privacy, the default choice could be not to mark or limit the marking to a portion of connections.

The idea would be to allow an user to make a global choice rather than forcing him to make it for each application, thus making the entire authorization process not very user friendly.



Best Regards,

Fabio B.



________________________________
Da: Explicit-meas <explicit-meas-bounces@ietf.org> per conto di Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Inviato: mercoledì 31 marzo 2021 19:48
A: Spencer Dawkins at IETF; Lubashev, Igor
Cc: explicit-meas@ietf.org; tsvwg@ietf.org; IETF IPPM WG (ippm@ietf.org); alexandre.ferrieux@orange.com; HAMCHAOUI Isabelle IMT/OLN; Cociglio Mauro; Ian Swett; quic@ietf.org
Oggetto: [EXT] Re: [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)

Hi Spencer, Igor, Ian, All,
It is interesting to look at the similar discussion for PLUS back in 2016 and the related concerns about endpoints sending information to network entities.
On the one hand, this draft describes several “explicit” measurement methods which send information to an on-path observer. But, on the other hand, it is worth mentioning that each one of the methods has different privacy implications. Different kinds of information are exposed to the on-path observer depending on which method is chosen.
For example the Spin bit exposes an end-to-end delay metric while the sQuare bit exposes only endpoint-to-observer loss metric. So, in principle, it is possible to choose the method or the combination of methods based on the level of security that must be guaranteed.

Regards,

Giuseppe


From: Explicit-meas [mailto:explicit-meas-bounces@ietf.org] On Behalf Of Spencer Dawkins at IETF
Sent: Tuesday, March 30, 2021 11:44 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: explicit-meas@ietf.org; tsvwg@ietf.org; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>rg>; alexandre.ferrieux@orange.com; HAMCHAOUI Isabelle IMT/OLN <isabelle.hamchaoui@orange.com>om>; Cociglio Mauro <mauro.cociglio=40telecomitalia.it@dmarc.ietf.org>rg>; Ian Swett <ianswett=40google.com@dmarc.ietf.org>rg>; quic@ietf.org
Subject: Re: [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)

Hi, Igor,

On Tue, Mar 30, 2021 at 11:11 AM Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>> wrote:
Thank you, Ian and Spencer.

Sorry for top posting (the thread could otherwise get a little long and I am using Outlook…).

Ian, we did consider privacy implications of the markings. Because all markings and internal counters are completely reset when there is a CID change, we did not see the markings compromise linkability during migrations. Otherwise, since the markings are minimal, we see them only disclosing the information they are meant to disclose – upstream/downstream loss.  We do discuss privacy-related implications of disclosing upstream/downstream loss in https://datatracker.ietf.org/doc/html/draft-ferrieuxhamchaoui-quic-lossbits-03#section-8. However, the discussion in the ID is theoretical and is not a result of large global study whose results are confirmed by independent third parties. I would be happy to collaborate on this with an interested PhD student or another researcher.

Spencer, I will review the PLUS minutes. In a setup when endpoints are sending information to unknown third parties, my immediate concern is less with the third parties being unknown and more with the extent of the information sent being unknown. After all, endpoints are already sending information to “unknown third parties” on path every time they communicate over the Internet. With the explicit measurements proposals, the set of “unknown third parties” is not changing. What endpoints must focus on is the information content of the signal. In any case, the abovementioned draft allows for endpoints to decide whether this signal is being sent AND ensures that a certain portion of all connections does not use this signaling (so connections explicitly opting out do not stand out).

This was exactly the concern PLUS tripped over (IMO).

The concern being expressed was that the PLUS format allocated a fixed-length field (IIRC) that did not define every bit in the fixed-length field, so in the mind of the SEC types, a (let's just say it out loud) mobile operator who also sends you your phone, so controls both ends, could start sending itself interesting bits of information without a user "opting in", OR knowing that they should be trying to "opt out".

PLUS happened at IETF 96 (in 2016), and I'm guessing that we are doing more with automated updates in 2021 than we were doing in 2016 (also the year QUIC was chartered, although Google had been using gQUIC for several years previously, so "change the behavior after a browser upgrade" was on our horizon).

One didn't have to be a mobile operator mailing you a cell phone to add interesting behaviors without you, the user, realizing that.

Brian and Mirja would remember the details better (they were at the front of the room, while I was in the back, where ADs usually live).

But that's what I was trying to describe. I hope it makes sense. And good luck. This was important work that we didn't know how to charter at the time (again, IMO).

Best,

Spencer

Delivery of qlog to specific operators is possible, but it does not help much to locate the source of the loss/delay (upstream of the operator? downstream? in the operator’s own systems?) – the primary goal of this draft.

Very best,


  *   Igor