Re: Opsdir last call review of draft-ietf-quic-manageability-14

[Lucas Pardue <[e-mail]>]

Hi,

Responses in line (from a chair that's been quietly observing)

On Wed, 23 Mar 2022, 21:38 MORTON JR., AL, <[e-mail]> wrote:

> goto end
> > -----Original Message-----
> > From: Gorry Fairhurst <[e-mail]>
> > Sent: Wednesday, March 23, 2022 6:27 AM
> > To: Brian Trammell (IETF) <[e-mail]>; MORTON JR., AL
> > <[e-mail]>
> > Cc: [e-mail]; Paul Vixie <[e-mail]>; [e-mail];
> > [e-mail]; Mirja Kuehlewind
> > <[e-mail]>; [e-mail]
> > Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14
> >
> > On 23/03/2022 11:00, Brian Trammell (IETF) wrote:
> > > Hi Al,
> > >
> > > (Snipping a bit of context)
> > >
> > >> On 22 Mar 2022, at 20:51, MORTON JR., AL <[e-mail]> wrote:
> > >>
> > >>>> In other words, the set of wire image features that can cause
> > >>>> differential treatment in an operator's network is equal to the set
> of
> > >>>> wire image features that are freely observable by that operator.
> > >>> see above. there are many reasons a network operator would look at
> her
> > >>> packets in order to diagnose problems not of her making.
> > >>>
> > >>> --
> > >>> P Vixie
> > >> [acm]
> > >>
> > >> I think Paul is on the right track with this last sentence. There are
> > several limiting assumptions in this thread about operator activities:
> > >>
> > >> + mid-path observations are only one of many ways to contribute to
> network
> > management. Launching QUIC connections from hosts under operator control
> is
> > another. Successful QUIC analysis seems to require different methods
> than with
> > TCP, and that's fine.
> > > This is entirely missing; indeed, the document treats active
> measurement
> > techniques (which I think are quite promising for management of encrypted
> > transports) as implicitly out of scope. I’m not sure it makes sense to
> expand
> > the scope of this doc (intended as a user’s guide to the wire image) in
> last
> > call, but perhaps we should add text to make this scope explicit.
> > >
> > >> + the "operator that wants to support QUIC" case seems to be an
> unexpected
> > role (so far). It would be useful to embrace this case in the
> manageability
> > draft, IMO.
> > > The disconnect in this thread, I think, is related to how large we
> think the
> > set of useful passive measurement actions requiring access to data not
> in the
> > wire image is. I think that most of these tasks are things we think are
> useful
> > with analogy to TCP, because we are *so used* to debugging TCP dynamics
> that
> > we have unseen biases toward doing things that way. Indeed, I think the
> actual
> > set tends toward empty, in part due to the (theoretical, perhaps
> tautological,
> > but not at all meant as a straw man dismissal, apologies as it came off
> as
> > such) analysis that the wire image you can see to troubleshoot is the
> same
> > wire image your devices can see to break things.
> [acm]
> The context of this point is only 10 lines away, but it seems it was
> quickly overlooked.
> The "operator that wants to support QUIC" doesn't want to break things.
> More below.
>
>
> > >
> > > It would be interesting to dig into specifics to see how wrong I am.
> I’m not
> > sure that’s in scope *this* document, though.
> > >
> > > Thanks, cheers,
> > >
> > > Brian
> >
> > If it helps: One possible way to deal with could be to describe the
> > scope within the QUIC WG for this document, and then note that there are
> > other operations-related considerations around the sort of transport
> > header confidentiality provided by QUIC and reference RFC 9065 as a list
> > of some considerations in this space.
> >
> > Trying to be helpful,
> >
> > Gorry
> >
>
> [acm]
> Multiple points here, thanks for continuing the discussion, friends. I'll
> try to be brief:
>
> + The scope limit that Brian is proposing PR#464 stops too short IMO, so:
>         This document also focuses solely on network management
>         practices that interact with traffic on the wire; replacement of
>         troubleshooting based on observation with active measurement
> techniques, for
>         example, is therefore out of scope.
> ADD something like:
>        Augmentation of passive observation using active measurement
> techniques, and simple
>        heuristics for management with observations at lower layers is for
> further study.
>        <plus cite Gorry and Colin's RFC 9094, section 2.4 at least)
>

RFC 9094 seems like a typo, unless there's something about QUIC and
switched optical networks I don't know
:-)

Regardless, speculating how people might choose to combine information
about QUIC and other stuff doesn't strike me as super useful. We should
just accept that it is given that the Internet and its management evolves.
People can try to evolve that how they want given the things we do take the
time to define.


> + The sentence above the PR#464 proposal:
>
>         This document therefore does not make any specific
>         recommendations as to which practices should or should not be
> applied;
>         for each practice, it describes what is and is not possible with
> the
>      QUIC transport protocol as defined.
>
> This might be pointing the way home for the "don't specify policy"
> objection/discussion.
> Brian, you indicated that this text:
>     ...purposes of network admission control should not rely on the
> version number
>     field. Instead it is recommended to admit all QUIC traffic
> regardless...
> is only a recommendation.
>
> But the scope says your memo is not making recommendations on practices.
> Network admission control is enforcement of policy.
>
> But it sounds like a version number is one of the few wire image features
> that the protocol designers deliberately revealed,  so when Section 4 of
> RFC 8558 recommends:
>
>    o  Anything exposed to the path should be done with the intent that
>       it be used by the network elements on the path. ...
>
> So, w.r.t. the wire image, the set of features that might support
> management "tends toward empty" but it's not zero and what's exposed might
> well be used by observers.
>

To my knowledge, nether QUIC v1 or the invariants (RFC 9000 and 8999
respectively) reference RFC 8558. So I would be very careful in inferring
the what and how about the intention of the visible portions. The version
is only carried in QUIC long packets and there are reasons for doing so
that benefit QUIC. RFC 8999 goes so far as saying about the version field "
This value can be used by endpoints to identify a QUIC version".

The space of definable versions is vast, and the possible behaviours
between endpoints are large. Throw in also QUIC extensions that are not
exposed in the wire image. These combine to limitless possibilities.
Attempting predictions of behaviour based on version in a small part of the
QUIC connection lifetime nets out as an insurmountable activity. What would
observers hope to achieve? Use of version for any management is a game of
whack-a-mole.

Cheers
Lucas