Re: [ippm] QUIC concerns relating to draft-ietf-ippm-explicit-flow-measurements

[Christian Huitema <[e-mail]>]

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 <[e-mail]>
>> Sent: Thursday, May 11, 2023 6:30 AM
>> To: [e-mail]
>> 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.
>