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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
