Hi Lucas, There seems to be a persistent indent at the points where I replied, so look for acm2. Al
From: Lucas Pardue <[email protected]> Sent: Friday, March 25, 2022 11:59 AM To: MORTON JR., AL <[email protected]> Cc: Gorry Fairhurst <[email protected]>; Brian Trammell (IETF) <[email protected]>; [email protected]; Paul Vixie <[email protected]>; [email protected]; [email protected]; Mirja Kuehlewind <[email protected]>; QUIC WG <[email protected]> Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14 Hey Al, Response in line On Fri, 25 Mar 2022, 16:26 MORTON JR., AL, <[email protected]<mailto:[email protected]>> wrote: Hi Lucas, response below. From: Lucas Pardue <[email protected]<mailto:[email protected]>> Sent: Wednesday, March 23, 2022 8:02 PM To: MORTON JR., AL <[email protected]<mailto:[email protected]>> Cc: Gorry Fairhurst <[email protected]<mailto:[email protected]>>; Brian Trammell (IETF) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Paul Vixie <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Mirja Kuehlewind <[email protected]<mailto:[email protected]>>; QUIC WG <[email protected]<mailto:[email protected]>> Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14 Hi, Responses in line (from a chair that's been quietly observing) On Wed, 23 Mar 2022, 21:38 MORTON JR., AL, <[email protected]<mailto:[email protected]>> wrote: goto end > -----Original Message----- > From: Gorry Fairhurst <[email protected]<mailto:[email protected]>> > Sent: Wednesday, March 23, 2022 6:27 AM > To: Brian Trammell (IETF) <[email protected]<mailto:[email protected]>>; MORTON > JR., AL > <[email protected]<mailto:[email protected]>> > Cc: [email protected]<mailto:[email protected]>; Paul Vixie > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > Mirja Kuehlewind > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]> > 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 > >> <[email protected]<mailto:[email protected]>> 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 [acm] Given the case "operator that wants to support QUIC" we are discussing, Whack-a-Mole is the worst-analogy-ever. QUIC is for endpoints, so I don't really know what a operator that wants to support QUIC is supposed to do other than allow that traffic or try to an endpoint. [acm2] Try to *operate* an endpoint? Yes, exactly. If the operator sees the same symptoms as a user reported, then the trouble-shooting continue on that basis. This is virtually always the simplest first step: can we reproduce the issue? It’s easier than packet trace analysis. For non-QUIC endpoints, conflating QUIC version fields with the behaviour of the QUIC protocol and/the QUIC connection flows is bad. There are too many variables, beyond the version, and within the encryption layer, that affect behavior. Under this context I'd stand by the analogy. [acm2] Sure, but the version field with a published specification might narrow the possibilities. In the "operator that wants to support QUIC", no one holds a hammer and no one gets whacked. But if you insist on this analogy, know that I lived on the New Jersey Shore for 65 years and spent a lot of time in arcades. I have friends and family who are absolute savants at Whack-a-Mole. "don't specify policy" is a separate but overlapping issue. Admission control is enforcement of policy. Don’t try to specify operator policy. Re-word the (wg consensus) statement concerning version numbers. In that case, all I can suggest is to say fewer words. For exakple, converting the last para in section 2.8 to say only QUIC is expected to evolve rapidly, so new versions, both experimental and IETF standard versions, will be deployed on the Internet more often than with traditional Internet- and transport-layer protocols. Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows and completely fail in the near future, and is therefore not recommended. Similarly, it is not recommended to use the version to distinguish QUIC traffic from non-QUIC traffic. Applying these suggestions could, for example, allow all QUIC traffic regardless of version, which in turn would support continious version-based evolution and avoid unnecessary delays for endpoints that wish to deploy new versions. But I'm not sure if that actually addresses your point. [acm2] That’s mostly fine: the sentences with the phrase “not recommended” don’t follow (in IMO) the part of the scope that says: 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. and these could be re-worded as statements of fact/future direction. The memo (scope) stops way-short of describing active management activities that have potential benefit, given the many intentional difficulties with passive observation that are present (with due respect to the management possibilities discussed in sections 3 and 4 of the memo). It would be good to summarize only the productive (passive) observations in a table or list for the intended audience. The case "operator that wants to support QUIC" seems to have been under-represented during development (and it needs frequent reminders in this discussion). And that’s one reason IETF has OPS-DIR Reviews. We appreciate your review and feedback specially, and the wider IETF reviews in general. Thanks. Cheers Lucas
