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

[Spencer Dawkins at IETF <[e-mail]>]

Just one observation, that's relevant to an Al question. Snipping down to

On Fri, Feb 11, 2022 at 11:21 AM Mirja Kuehlewind <mirja.kuehlewind=
[e-mail]> wrote:

> Hi Al,
>
> thanks for your review. Glad to hear that you find the draft useful. I
> think your input is very valuable for this draft as you are part of the
> intended audience, however, not sure how/if to address many of your
> comments. But let me try provide some explanations. Please see inline
> marked with [MK].
>
> Mirja
>
>
> On 05.02.22, 23:11, "QUIC on behalf of Al Morton via Datatracker" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>        In addition, due to the speed of evolution of the
>        protocol, devices that attempt to distinguish QUIC traffic from non-
>        QUIC traffic for purposes of network admission control should admit
>        all QUIC traffic regardless of version.
>
>     [acm] I was hoping to see a description of fallback to TCP (I see that
> fallback
>     is mentioned briefly at the end of section 4.2., and later, fail over
> and
>     failover. pick one...)
>
>     How can Network Operators observe when a QUIC setup has failed, and the
>     corresponding TCP fallback connection(s) succeeded?
>
> [MK] There is no unified way how and if fallback is implemented. However,
> why do you think a network operator would need that information?
>

 On the left hand side of Mirja's response, we spent a LOT of time talking
about what QUIC (more properly, HTTP) would do if UDP blocking or severe
rate limiting prevented a path from being usable for HTTP/3.

In the HTTP case, giving up on HTTP/3 over QUIC over UDP is obvious
(because the path isn't usable for HTTP/3). If you insist on continuing to
use HTTP, you'll use HTTP/1 or HTTP/1.1 or HTTP/2, all over TCP, which
won't be affected by network treatment of UDP.

I remember having a conversation with Brian about what it means for the
Internet architecture that some applications that might make use of QUIC do
have obvious strategies when QUIC (or UDP) blocking happens, and other
applications do not.

There's quite a bit of discussion about this in
https://www.ietf.org/archive/id/draft-ietf-quic-applicability-14.html#name-the-necessity-of-fallback
.

If I'm tracking the discussion in this thread, I wonder if the
manageability draft, which already points to the applicability draft, needs
to say more than

   - A passive observer can't consistently tell whether QUIC handshakes
   succeed or fail, and
   - A passive observer can't know what QUIC applications will do next in
   the general case if their handshakes fail.

But I think the answer to the right hand side of Mirja's response is needed
for us to Do The Right Thing.

Best,

Spencer