scroll down...
> -----Original Message-----
> From: Paul Vixie <paul@xxxxxxxxxxx>
> Sent: Tuesday, March 22, 2022 12:54 PM
> To: Brian Trammell (IETF) <ietf@xxxxxxxxxxx>
> Cc: MORTON JR., AL <acmorton@xxxxxxx>; last-call@xxxxxxxx; draft-ietf-quic-
> manageability.all@xxxxxxxx; quic@xxxxxxxx; ops-dir@xxxxxxxx; Mirja Kuehlewind
> <mirja.kuehlewind@xxxxxxxxxxxx>
> Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14
>
>
> 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
[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.
+ 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.
Al
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
