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=40ericsson.com@xxxxxxxxxxxxxx> 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" <quic-bounces@xxxxxxxx on behalf of noreply@xxxxxxxx> 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
