HTTP/3 seems to offer all these benefits already... And seems to be simpler and more compatible... And doesn't require a new DNS field which will surely trip up plenty of middleboxes...
Without taking a position on TurboTLS versus H3...
There are actually two types of middlebox problems:
1. DNS resolvers which don't carry new record types.
2. Middleboxes which don't properly handle UDP-based protocols
(2) applies to both H3 and to TurboTLS, and in both cases you need some kind of fallback in case things fail.
(2) applies to TurboTLS as specified. However, it's worth noting that H3 also has a DNS-based mechanism for advertising support via the HTTPS record (that is also used for ECH). However, you can also advertise H3 support via Alt-Svc, so presumably you could do the same with TurboTLS.
In general, any new transport like H3 or TurboTLS has to be offered on a best-effort basis with a fallback, otherwise you'll have a lot of hard failures.
> However, you can also advertise H3 support via Alt-Svc, so presumably you could do the same with TurboTLS.
Alt-Svc is an http header, by the time you get http you already have TLS setup. In a Alt-Svc workflow you generally advertise h2 in TLS ALPN, then use Alt-Svc to advertise h3 capability in the headers of the first response, and then the client establishes a h3 connection and closes the h2 connection when it is ready (and the h2 connection does not have any queued requests). At least that is my understanding.
Yes, that's correct. Basically the only good way to have a "first contact" fast track setup like this is by priming in DNS. My point is that the situation is th same for TurboTLS and QUIC/H3 in this respect.
I just meant that QUIC/H3 is beneficial even after you already have a connection, so upgrading an existing connection is a valid strategy. TurboTLS is only beneficial for establishing the connection, so it needs to have prior knowledge about the support to be useful at all.
HTTP/3 is based on QUIC, and these perf properties are due to QUIC, not H3.
With that said, the unusual performance dynamics of the Web make connection setup latency particularly important by contrast to, for instance, SMTP, where people don't really get bent out of shape if a message takes another 200ms to be delivered.
