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

[Paul Vixie <[e-mail]>]

Brian Trammell (IETF) wrote on 2022-03-22 07:42:
> Hi Al,

not al, but see inline.

>>> [mk]
>>> Regarding when the handshake fails, I'm not sure if it would be 
>>> correct to say anything more here. You can always just not see
>>> some of the packets on the path, or the handshake could even
>>> change with a new version or an extension I guess. Again I'm also
>>> not really sure what to do with that information either. If you
>>> don't see any further packets flowing at any time, incl. right 
>>> after the handshake, something went either wrong or the
>>> transmission is just done. It's really hard to make any
>>> assumption from the network here.
>> [acm]
>> The case I cited was an operator that wants to support QUIC, and wants 
>> to identify when QUIC setup fails and how frequently failure occurs, 
>> to support analysis and troubleshooting and properly manage their network.
> [bt]
> There seems to be a tacit assumption here that holds in the TCP case 
> that does not necessarily hold in the QUIC case: that an operator can 
> helpfully debug the operation and performance of a transport protocol 
> within their network. ...

perhaps not necessarily, but often, it does hold.

> ... One of the reasons this is a useful (indeed, essential) role of
> network operators in the TCP world is that there is often an
> unavoidable, unintentional, transport-dependent differential impact
> of an operator’s own network on different traffic flows, where the
> remedy is often only actionable by the operator itself.

that is indeed one of the reasons, but there are others, including the 
one given by al above, and including debugging of PMTUD (now PLPMTUD) 
where the damage may be occurring upstream (far from "the operator 
himself" who in this story is trying to diagnose setup fails. we could 
try to enumerate a much larger set of reasons, but i don't think that 
would be helpful.

> I’d submit that the main reason this happens with protocols like TCP is 
> that the TCP wire image is path-observable and path-mutable. Without 
> this path-observability and path-mutability, the set of possible 
> flow-dependent impacts is necessarily reduced, if not eliminated. ...

i'd agree that the "main reason" that the thing you narrowed earlier 
("differential impact of an operator's own network") is made possible 
only by TCP's path-observability and path-mutability. however, that's 
both a tautology in its own right, and a straw man dismissal of what al 
actually said.

> 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