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

[Lucas Pardue <[e-mail]>]

Hey Igor,

On Thu, May 11, 2023 at 3:54 PM Lubashev, Igor <ilubashe=
[e-mail]> wrote:

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

In theory its feasible. In practice the current approach risks burning
those bits if operators read draft-ietf-ippm-explicit-flow-measurements and
start to assume they can look at QUIC packets at any arbitrary point duing
a flow and the bits mean something, or if they can avoid doing hard and
complex work. I think we need to be very explicit and say that on-path
observers hoping to use these bits have to be completely confident in
establishing how those bits are used in each and every individual
connection. That means either determining the precise QUIC version that was
negotiated, or the union of Transport Parameters that were exchanged. The
transport parameters confidence is tricky because of the extensibility and
composability extensions. If the observer doesn't understand an extension
that the client and server are speaking, it could draw the wrong
conclusions about the behaviour of the bits.

We shouldn't assume that on-path observers will understand these nuances of
QUIC. Observers need to be prepared for the situation where that cannot,
and maybe never will know, how the bits in a flow are really being used,
and what to do in such failure conditions. Lets assume operators will act
in good faith and that if we point out the concerns with big "warning
label"s, that's the best we can probably do. That would probably be
sufficient to address my concerns and allow us to proceed.

Cheers,
Lucas