RE: Opsdir last call review of draft-ietf-quic-manageability-14

["MORTON JR., AL" <[e-mail]>]

goto end
> -----Original Message-----
> From: Gorry Fairhurst <[e-mail]>
> Sent: Wednesday, March 23, 2022 6:27 AM
> To: Brian Trammell (IETF) <[e-mail]>; MORTON JR., AL
> <[e-mail]>
> Cc: [e-mail]; Paul Vixie <[e-mail]>; [e-mail];
> [e-mail]; Mirja Kuehlewind
> <[e-mail]>; [e-mail]
> 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 <[e-mail]> 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)  

+ 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.

Al