Igor is right. In fact, the "square bit" that he describes is
implemented in Picoquic, under an option negotiation.
The issues are exactly the same as what led to the long discussion of
the spin bit. Exposing ways to better calculate RTT can be use to trace
the origin and end of calls, and detect for example if the call
continues in a proxy. So we have a tradeoff between privacy and
measurements, which typically leads to not turning on such features by
default, but only in special circumstance such as, for example, debugging.
The probability that these measurement features be turned on by default
is extremely low, and the draft should be very explicit about it,
including a description of the privacy/measurement tradeoff.
-- Christian Huitema
On 5/11/2023 7:23 AM, Lubashev, Igor wrote:
Matrin, the measurements described are not only feasible, but they are also
feasible without an introduction of any new versions of QUIC. It just takes a
regular Transport Parameter negotiation in QUIC v1.
See
https://datatracker.ietf.org/doc/html/draft-ferrieuxhamchaoui-quic-lossbits-03
- Igor
-----Original Message-----
From: Martin Thomson <m...@lowentropy.net>
Sent: Thursday, May 11, 2023 6:30 AM
To: quic@ietf.org
Subject: Re: [ippm] QUIC concerns relating to draft-ietf-ippm-explicit-flow-
measurements
On Thu, May 11, 2023, at 19:44, Giuseppe Fioccola wrote:
I think your concerns about QUIC are reasonable, but they can be taken
into account only for the specific application to QUIC, that would
eventually be defined in a separate draft.
I think that Lucas' point is that the draft describes something that isn't
likely
to ever be feasible. At a minimum, the draft should be clear about the
conditions that would be necessary to realize this goal. From what I can see,
the conditions involve deploying a new version of QUIC that completely
displaces the existing version of QUIC, which - if not completely impossible -
is at least highly improbable.
