mjoras

There's a lot of significant differences from the original Google QUIC design and what we currently have in the IETF drafts. They are very much wire-incompatible. That's why it took several years for the working group to get to a point where they were near-completion.

Policy reasons is all I can say unfortunately.

Indeed. I believe the latest Windows Insiders builds have SMB over QUIC support (via msquic). I think QUIC brings a lot potential to finally run network filesystem protocols on the Internet.

This is how the IETF and protocol development works[1]. In fact, it is strongly encouraged for participants to implement and deploy drafts before they are finalized. Otherwise you risk finalizing something with a lot of deployment problems.

[1]https://www.ietf.org/how/runningcode/

Most implementations[1] implement it in userland, but this is by no means a requirement. There is no implementation for the Linux kernel presently, but both msquic and F5's QUIC implementation can run in their respective kernels.

QUIC is indeed built on top of UDP datagrams, much in the same way TCP is built (typically) on top of IP datagrams.

[1] https://github.com/quicwg/base-drafts/wiki/Implementations

There are several efforts to implement QUIC and HTTP/3 in nginx. Cloudflare has it deployed in production with quiche[1], and Nginx themselves are developing one[2].

Applications sitting behind a proxy wouldn't need to be updated. The core protocol semantics of HTTP are relatively unchanged between HTTP/1.1, HTTP/2, and HTTP/3.

[1] https://github.com/cloudflare/quiche

[2] https://www.nginx.com/blog/introducing-technology-preview-ng...

As I said below, the blog is more focused on QUIC itself rather than HTTP/3. The bulk of the improvements we see are from QUIC as a transport layer, rather than the changes in HTTP/3.

We never deployed Google QUIC. It was always IETF QUIC. Referring to them together as QUIC was just for expedience, since the main benefits came from the QUIC layer, not the HTTP layer.

HTTP/3 implies IETF QUIC. IETF QUIC itself can be used for non-HTTP protocols, though, just like TCP can be used for protocols that aren't HTTP/2.

There's no reason the offloads can't work with QUIC. Linux already has UDP GSO (https://lwn.net/Articles/752184/). There's no technical reason I can think of that kTLS cannot be implemented for UDP on Linux, it's just not there today.

There are also more general efforts underway on Linux to reduce the system call and copying overhead of processing packets in userspace. TPACKET_V3 is an easy way to vastly increase the scalability of UDP recv processing with minimal application changes. AF_XDP is much more extreme, but it is going to be more implementable than the older DPDK-style semantics. It effectively will put packet buffer management into userspace with the transport. But once you're doing that have recaptured much of the advantages that TCP has by running in the kernel.