Hi,
Responses in line (from a chair that's been quietly observing)
On Wed, 23 Mar 2022, 21:38 MORTON JR., AL, <acmorton@xxxxxxx> wrote:
goto end
> -----Original Message-----
> From: Gorry Fairhurst <gorry@xxxxxxxxxxxxxx>
> Sent: Wednesday, March 23, 2022 6:27 AM
> To: Brian Trammell (IETF) <ietf@xxxxxxxxxxx>; MORTON JR., AL
> <acmorton@xxxxxxx>
> Cc: ops-dir@xxxxxxxx; Paul Vixie <paul@xxxxxxxxxxx>; last-call@xxxxxxxx;
> draft-ietf-quic-manageability.all@xxxxxxxx; Mirja Kuehlewind
> <mirja.kuehlewind@xxxxxxxxxxxx>; quic@xxxxxxxx
> 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 <acmorton@xxxxxxx> 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
