Subject: Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)

From: Cociglio Mauro <[email-masked]>
Date: Tue, 16 Mar 2021 13:47:51 +0000

Hi.
Last Friday during the IPPM meeting,  after the "Explicit Flow Measurements" draft presentation (https://tools.ietf.org/html/draft-mdt-ippm-explicit-flow-measurements-01), Greg Mirsky raised an issue that I think is very important.
The question is about differences and similarities between the two types of production traffic packet marking for performance measurements, proposed in IETF and initiated in the IPPM WG: Alternate Marking and Explicit Flow Measurements.

The first technique known as Alternate Marking or AM/PM (Alternate Marking Performance Monitoring) is defined, in general terms, in RFC8321 (the point-to-point version) and RFC8889 (the multipoint version).
It is essentially a Telco measurement, born to measure packet delay and loss between the input and output of a network, or between 2 internal points of the network, in order to identify and localize a problem. It is a network measure and it is the network operator that performs the marking by modifying packets on the fly.
The strength of this technique comes from the decoupling of marking and measurement. We can mark all traffic, using a fixed marking interval (typically "big": from 1 second up to 5 minutes), then we decide what to measure based on the resources I want to use. In case of packet loss measurement we can start from a single packet counter for all traffic for each measurement point (possibility described in RFC8889), to have a network measurement, to arrive to a counter for each point-to-point connection you want to monitor (as described in RFC8321).
In order to obtain the measurement it is necessary to compare the data collected from at least 2 measurement points (counters for packet loss, timestamps for delay). Then a "communication" between measurement points, or with a Network Measurement Center, is needed.
There are already commercial implementations of this technique (also for IPv4) and IETF drafts that are standardizing it for various protocols (IPv6, MPLS, Segment Routing, BIER, ...).
The Alternate Marking methodology is evolving into the draft "Big Data AltMark" (https://tools.ietf.org/html/draft-c2f-ippm-big-data-alt-mark-01) that defines point-to-point flows measurements applying post processing to performance data collected by sampling a single network multipoint flow.

The second marking technique for performance monitoring of packet networks has been called Explicit Flow Measurements (EFM), and is more recent because it's born with the Spin bit RTT measurement. And it came about primarily to have an end-to-end performance measure, from the terminal, on which an application is running, to the server at the opposite end of the network. EFM can be seen as complementary measures to Alternate Marking.
It requires certain characteristics of the protocols to which it can be applied, which are client-server, and it is particularly convenient for protocols that prevent the marking of packets on the fly (e.g. QUIC), because the marking occurs only on the end-points of the connection.
The disadvantage with respect to the previous technique is that it always works for client-server point-to-point connection, it is not possible to aggregate measurements saving on monitoring resources as described in RFC8889. The advantage is that it can also work with a single monitoring point, even if having more points enhances it and allows intradomain measurements. With a single measurement point you can obtain end-to-end measures (Spin bit, Delay bit for delay and Loss bit, rT loss bit for packet loss) or end-to-observer measures (sQuare bit and Reflection bit for packet loss). End-to-observer measurements and scalability considerations make it particularly convenient to place a measurement point on the client (see https://tools.ietf.org/html/draft-cnbf-ippm-user-devices-explicit-monitoring-01).

Best Regards.

Mauro
_____________________
Mauro Cociglio
TIM - Telecom Italia
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.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Sat, 27 Mar 2021 20:28:56 +0000

Thank you, Mauro.

I would like to point out to IPPM WG that some of the proposed measurement techniques have already been implemented and had been running on the Internet in 2019 and 2020.  Namely, Akamai has implemented Loss Bits (L+Q) and enabled them on a large portion of QIUC traffic served to Orange Telecom users in several countries, while Orange implemented observers that collected and analyzed the measurements.  We have discussed the measurements and techniques in MAPRG during IETF-105 (and at other WGs and meetings).

Here is our IETF-105 MAPRG presentation discussing the data https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-packet-loss-signaling-for-encrypted-protocols-01.

In short, we found that unidirectional observations of QUIC traffic with L+Q bits alone to be effective for measuring both upstream and downstream packet loss and characterizing the magnitude of packet reordering.

During the last meeting Ian asked whether Akamai would implement and enable these measurements techniques for QUIC on the large scale, if all the relevant drafts get standardized by IETF.  The answer is that, yes, we would.  We are very interested in doing what it takes to improve Internet performance for the users, and we would work hard to implement techniques that can help network operators to improve QOS on their networks.

- Igor

> -----Original Message-----
> From: Cociglio Mauro <mauro.cociglio=[email-masked]>
> Sent: Tuesday, March 16, 2021 9:48 AM
> To: IETF IPPM WG ([email-masked]) <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [ippm] Comparing Alternate Marking and Explicit Flow
> Measurements (Spin bit, ...)
> 
> Hi.
> Last Friday during the IPPM meeting,  after the "Explicit Flow Measurements"
> draft presentation
> (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-mdt-ippm-
> explicit-flow-measurements-01__;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J-D-
> O99Zvrz686frIu4shWxPEipwQd7TTuOM3NTyNCU$ ), Greg Mirsky raised an
> issue that I think is very important.
> The question is about differences and similarities between the two types of
> production traffic packet marking for performance measurements, proposed
> in IETF and initiated in the IPPM WG: Alternate Marking and Explicit Flow
> Measurements.
> 
> The first technique known as Alternate Marking or AM/PM (Alternate
> Marking Performance Monitoring) is defined, in general terms, in RFC8321
> (the point-to-point version) and RFC8889 (the multipoint version).
> It is essentially a Telco measurement, born to measure packet delay and loss
> between the input and output of a network, or between 2 internal points of
> the network, in order to identify and localize a problem. It is a network
> measure and it is the network operator that performs the marking by
> modifying packets on the fly.
> The strength of this technique comes from the decoupling of marking and
> measurement. We can mark all traffic, using a fixed marking interval (typically
> "big": from 1 second up to 5 minutes), then we decide what to measure
> based on the resources I want to use. In case of packet loss measurement
> we can start from a single packet counter for all traffic for each measurement
> point (possibility described in RFC8889), to have a network measurement, to
> arrive to a counter for each point-to-point connection you want to monitor
> (as described in RFC8321).
> In order to obtain the measurement it is necessary to compare the data
> collected from at least 2 measurement points (counters for packet loss,
> timestamps for delay). Then a "communication" between measurement
> points, or with a Network Measurement Center, is needed.
> There are already commercial implementations of this technique (also for
> IPv4) and IETF drafts that are standardizing it for various protocols (IPv6,
> MPLS, Segment Routing, BIER, ...).
> The Alternate Marking methodology is evolving into the draft "Big Data
> AltMark" (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
> c2f-ippm-big-data-alt-mark-01__;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J-D-
> O99Zvrz686frIu4shWxPEipwQd7TTuOM_yNIIgs$ ) that defines point-to-point
> flows measurements applying post processing to performance data collected
> by sampling a single network multipoint flow.
> 
> The second marking technique for performance monitoring of packet
> networks has been called Explicit Flow Measurements (EFM), and is more
> recent because it's born with the Spin bit RTT measurement. And it came
> about primarily to have an end-to-end performance measure, from the
> terminal, on which an application is running, to the server at the opposite
> end of the network. EFM can be seen as complementary measures to
> Alternate Marking.
> It requires certain characteristics of the protocols to which it can be applied,
> which are client-server, and it is particularly convenient for protocols that
> prevent the marking of packets on the fly (e.g. QUIC), because the marking
> occurs only on the end-points of the connection.
> The disadvantage with respect to the previous technique is that it always
> works for client-server point-to-point connection, it is not possible to
> aggregate measurements saving on monitoring resources as described in
> RFC8889. The advantage is that it can also work with a single monitoring
> point, even if having more points enhances it and allows intradomain
> measurements. With a single measurement point you can obtain end-to-end
> measures (Spin bit, Delay bit for delay and Loss bit, rT loss bit for packet loss)
> or end-to-observer measures (sQuare bit and Reflection bit for packet loss).
> End-to-observer measurements and scalability considerations make it
> particularly convenient to place a measurement point on the client (see
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-cnbf-ippm-
> user-devices-explicit-monitoring-01__;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J-
> D-O99Zvrz686frIu4shWxPEipwQd7TTuOMvZGbbWs$ ).
> 
> Best Regards.
> 
> Mauro
> _____________________
> Mauro Cociglio
> TIM - Telecom Italia
> Via G. Reiss Romoli, 274
> 10148 - Torino (Italy)
> Tel.: +390112285028
> Mobile: +393357669751
> _____________________
> 
> 
> 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.
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm_
> _;!!GjvTz_vk!CC-VjNQml5au1pXfCN50J-D-
> O99Zvrz686frIu4shWxPEipwQd7TTuOMMXmeW4s$

---

From: Ian Swett <[email-masked]>
Date: Mon, 29 Mar 2021 08:00:00 -0400

Thanks for the maprg slides Igor, it's great to hear you'd enable this if
it was standardized.

<Taking off my WG chair hat>

Has Akamai conducted any privacy analysis it would be willing to share with
the IETF?  For this to be widely deployed, I think that will need to be
done, similar to the spin bit.

On Sat, Mar 27, 2021 at 4:29 PM Lubashev, Igor <[email-masked]> wrote:

> Thank you, Mauro.
>
> I would like to point out to IPPM WG that some of the proposed measurement
> techniques have already been implemented and had been running on the
> Internet in 2019 and 2020.  Namely, Akamai has implemented Loss Bits (L+Q)
> and enabled them on a large portion of QIUC traffic served to Orange
> Telecom users in several countries, while Orange implemented observers that
> collected and analyzed the measurements.  We have discussed the
> measurements and techniques in MAPRG during IETF-105 (and at other WGs and
> meetings).
>
> Here is our IETF-105 MAPRG presentation discussing the data
> https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-packet-loss-signaling-for-encrypted-protocols-01
> .
>
> In short, we found that unidirectional observations of QUIC traffic with
> L+Q bits alone to be effective for measuring both upstream and downstream
> packet loss and characterizing the magnitude of packet reordering.
>
> During the last meeting Ian asked whether Akamai would implement and
> enable these measurements techniques for QUIC on the large scale, if all
> the relevant drafts get standardized by IETF.  The answer is that, yes, we
> would.  We are very interested in doing what it takes to improve Internet
> performance for the users, and we would work hard to implement techniques
> that can help network operators to improve QOS on their networks.
>
> - Igor
>

One question on this.  As a QUIC WG member I was under the impression the
spin bit would enable measurement within networks, but I agree that it is
best as an end-to-end measurement.  However, network endpoints can and
do(ie: qlog) export metrics and traces to provide detailed information
that's much richer than spin or loss bits, which makes me less clear on the
value of EFM.  Igor indicated it worked as intended, but there is the
separate question of whether it provides enough value on top of endpoint
logging and Alternate Marking.

> > Tel.: +390112285028 <+39%20011%20228%205028>
> > Mobile: +393357669751 <+39%20335%20766%209751>
> > _____________________
> >
> >

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 29 Mar 2021 08:03:48 -0500

Hi, Ian,

> <Taking off my WG chair hat>

I didn't notice that you're an IPPM co-chair - congratulations to you, and
to IPPM!

> Has Akamai conducted any privacy analysis it would be willing to share
> with the IETF?  For this to be widely deployed, I think that will need to
> be done, similar to the spin bit.
>

Exactly, because (please see below)

>> I would like to point out to IPPM WG that some of the proposed
>> measurement techniques have already been implemented and had been running
>> on the Internet in 2019 and 2020.  Namely, Akamai has implemented Loss Bits
>> (L+Q) and enabled them on a large portion of QIUC traffic served to Orange
>> > (
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-mdt-ippm-
>> > AltMark" (
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-

Brian Trammell and I have both been chatting with the TSV ADs about topics
that the PLUS BOF was relevant to. My recollection from
https://datatracker.ietf.org/doc/minutes-96-plus/ was that most of the
concern expressed by the SEC types in the room was about endpoints sending
information to network entities that the user was not aware of (and, truth
be told, that one concern detailed PLUS forevermore). (*)

(*) corrections on that point are welcome, but I'd be surprised if anyone
offered one. It wasn't a close BOF result.

It's obvious to me that relying on qlog plus delivery of qlog output to
network elements would be useful, and a lot more likely to be accurate than
inferences from a heavily encrypted byte stream, but please ask very early
in the process whether there's a similar concern about unwitting (from the
user's perspective) leakage to operators, or just bite the bullet and do
the privacy analysis now.

And Good Luck.

Best,

Spencer

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 30 Mar 2021 16:11:00 +0000

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).

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

From: Spencer Dawkins at IETF <[email-masked]>
Sent: Monday, March 29, 2021 9:04 AM

Hi, Ian,

On Mon, Mar 29, 2021 at 7:01 AM Ian Swett <ianswett=[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the maprg slides Igor, it's great to hear you'd enable this if it was standardized.

I didn't notice that you're an IPPM co-chair - congratulations to you, and to IPPM!

Has Akamai conducted any privacy analysis it would be willing to share with the IETF?  For this to be widely deployed, I think that will need to be done, similar to the spin bit.

On Sat, Mar 27, 2021 at 4:29 PM Lubashev, Igor <[email-masked]<mailto:[email-masked]>> wrote:
Thank you, Mauro.

Here is our IETF-105 MAPRG presentation discussing the data https://datatracker.ietf.org/meeting/105/materials/slides-105-maprg-packet-loss-signaling-for-encrypted-protocols-01<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/105/materials/slides-105-maprg-packet-loss-signaling-for-encrypted-protocols-01__;!!GjvTz_vk!Dujw9V18lqGrXL8GUOd79MFlesJpdVXn5R0Q-0m9rU-AQOyxjrwEflbtDIcQmfQ$>.

- Igor

> From: Cociglio Mauro <mauro.cociglio=[email-masked]<mailto:[email-masked]>>
> To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-mdt-ippm-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-mdt-ippm->
> AltMark" (https://urldefense.com/v3/__https://tools.ietf.org/html/draft-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft->

One question on this.  As a QUIC WG member I was under the impression the spin bit would enable measurement within networks, but I agree that it is best as an end-to-end measurement.  However, network endpoints can and do(ie: qlog) export metrics and traces to provide detailed information that's much richer than spin or loss bits, which makes me less clear on the value of EFM.  Igor indicated it worked as intended, but there is the separate question of whether it provides enough value on top of endpoint logging and Alternate Marking.

Brian Trammell and I have both been chatting with the TSV ADs about topics that the PLUS BOF was relevant to. My recollection from https://datatracker.ietf.org/doc/minutes-96-plus/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/minutes-96-plus/__;!!GjvTz_vk!Dujw9V18lqGrXL8GUOd79MFlesJpdVXn5R0Q-0m9rU-AQOyxjrwEflbtMqEnAT0$> was that most of the concern expressed by the SEC types in the room was about endpoints sending information to network entities that the user was not aware of (and, truth be told, that one concern detailed PLUS forevermore). (*)

(*) corrections on that point are welcome, but I'd be surprised if anyone offered one. It wasn't a close BOF result.

It's obvious to me that relying on qlog plus delivery of qlog output to network elements would be useful, and a lot more likely to be accurate than inferences from a heavily encrypted byte stream, but please ask very early in the process whether there's a similar concern about unwitting (from the user's perspective) leakage to operators, or just bite the bullet and do the privacy analysis now.

And Good Luck.

Best,

Spencer

> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-cnbf-ippm-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-cnbf-ippm->
> Tel.: +390112285028<tel:+39%20011%20228%205028>
> Mobile: +393357669751<tel:+39%20335%20766%209751>
> _____________________
>
>
> [email-masked]<mailto:[email-masked]>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm_<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ippm_>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 30 Mar 2021 16:44:24 -0500

Hi, Igor,

On Tue, Mar 30, 2021 at 11:11 AM Lubashev, Igor <[email-masked]> wrote:

> 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
>
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Wed, 31 Mar 2021 17:48:54 +0000

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:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Tuesday, March 30, 2021 11:44 PM
To: Lubashev, Igor <[email-masked]>
Cc: [email-masked]; [email-masked]; IETF IPPM WG ([email-masked]) <[email-masked]>; [email-masked]; HAMCHAOUI Isabelle IMT/OLN <[email-masked]>; Cociglio Mauro <mauro.cociglio=[email-masked]>; Ian Swett <ianswett=[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Thank you, Ian and Spencer.

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

Very best,

  *   Igor