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

["Lubashev, Igor" <[e-mail]>]

> On Thursday, May 11, 2023 at 10:24 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.

To expand on this, we mentioned example ways one could implement the measurement (including the reserved header bits in QUIC and UDP Surplus space; we could have also included my favorite "2 most significant bits of IP TTL" but did not) specifically to alleviate concerns that this is nice in theory but not feasible in practice.

We also added discussion of Ossification Considerations and Security Considerations specifically to alleviate the concerns that this is inherently dangerous to the protocols or to user Privacy.  This has been prompted by feedback we received from IETF community.

As Giuseppe said, resolving protocol-specific implementation detail or anti-ossification techniques is not the goal of this draft.  This draft introduces a set of techniques and algorithms.  Adapting them (or, more likely, just one or two of them) to specific protocols would be a matter of different drafts.  This draft is QUIC-inspired, but it is not QUIC-focused.

If IETF community believes that the draft would be better without any reference to potential implementation points, to avoid confusion, I can be happy to make the changes (I think my co-authors would not object either).

- Igor