| Hi Al,
Top-posting a summary: I think these are all interesting questions, I think we as a community should continue working to answer them. I’m still not sure they’re all in scope for this document. Some details inline… 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.
I think we’re talking past each other here, which makes me sad.
I’m not saying the that the "operator that wants to support QUIC” wants to break things.
I’m saying that the properties of QUIC’s wire image make fixing things through passive measurement oriented troubleshooting less necessary, because the wire image itself has less surface for *unintentional* breakage.
[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)
I agree with this point wholeheartedly…
I’m not sure where the line on the scope of the document is if we add this, though — because then it would be reasonable to say we should point out all other areas for further work.
+ 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.
So that’s a very interesting question… IMO the exposure of the version number is an evolutionarily-conserved feature predating the publication of that advice in 8558, as our understanding of the properties of wire images as a community has evolved with our experience designing and deploying QUIC. Maybe the WG should have made different choices, but for now I think the advice in the document stands…
Thanks, cheers,
Brian
|
