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