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= [email protected]> 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" < > [email protected] on behalf of [email protected]> 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
