Hey Al, Response in line
On Fri, 25 Mar 2022, 16:26 MORTON JR., AL, <[email protected]> wrote: > Hi Lucas, response below. > > > > *From:* Lucas Pardue <[email protected]> > *Sent:* Wednesday, March 23, 2022 8:02 PM > *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 > > > > Hi, > > > > Responses in line (from a chair that's been quietly observing) > > On Wed, 23 Mar 2022, 21:38 MORTON JR., AL, <[email protected]> wrote: > > goto end > > -----Original Message----- > > From: Gorry Fairhurst <[email protected]> > > Sent: Wednesday, March 23, 2022 6:27 AM > > To: Brian Trammell (IETF) <[email protected]>; MORTON JR., AL > > <[email protected]> > > Cc: [email protected]; Paul Vixie <[email protected]>; [email protected]; > > [email protected]; Mirja Kuehlewind > > <[email protected]>; [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]> 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. 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. > > > "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. > > > 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
