Hi Brian, Al, Mirja, et al, Just a quick note to say thank you to all for this conversation and working towards some sort of consensus.
I personally think that the PRs that Brian has created are helpful, and are looking good. There is a definite, and ongoing tension between the operators' need to see into the traffic for management/filtering/malware protection/etc; and the users' needs for privacy - this tension makes these sorts of discussions somewhat fraught, and I'd like to thank everyone again for trying to see each other's viewpoints, and work towards text / a solution that we can all live with. While this compromise might not be perfect, is it good enough that we can all live with it? W On Tue, Apr 05, 2022 at 7:04 AM, Brian Trammell <[email protected]> wrote: > Hi Al, Lucas, all, > > I think I’ve distilled down this thread into two PRs: https://github.com/ > quicwg/ops-drafts/pull/466 on “recommendation” language generally, and > 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]> > *Sent:* Friday, March 25, 2022 11:59 AM > *To:* MORTON JR., AL <[email protected]> > *Cc:* Gorry Fairhurst <[email protected]>; Brian Trammell (IETF) <ietf@ > trammell.ch>; [email protected]; Paul Vixie <[email protected]>; last-call@ > ietf.org; [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]> 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) <ietf@ > trammell.ch>; [email protected]; Paul Vixie <[email protected]>; last-call@ > ietf.org; [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. > *[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 > > > _______________________________________________ > OPS-DIR mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ops-dir >
