Hi Al, Lucas, all, I think I’ve distilled down this thread into two PRs: https://github.com/quicwg/ops-drafts/pull/466 <https://github.com/quicwg/ops-drafts/pull/466> on “recommendation” language generally, and https://github.com/quicwg/ops-drafts/pull/467 <https://github.com/quicwg/ops-drafts/pull/467> rephrasing recommendations not to switch on version into an analysis of the tradeoffs (thanks Lucas for your help with these!). Please have a look and let me know whether those resolve this discussion.
Thanks, cheers, Brian > On 28 Mar 2022, at 16:46, MORTON JR., AL <[email protected]> wrote: > > 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] > <mailto:[email protected]>> > Sent: Friday, March 25, 2022 11:59 AM > 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 > > 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
