In estimates I've done, in its current un-accelerated state, it would at least triple the CPU cost per byte served on our CDN workload. We basically lose:

- sendfile

- ktls

- TSO

Its like stepping into a time machine and going back to the mid 90s. To send data with QUIC, we have to get byes from kernel into userspace, encrypt them in userspace, and then write them back to the kernel, where they travel down to the NIC an MTU at a time. Ugh.

It doesn't exist today, but there's nothing preventing a kernelspace implementation of sendfileq (or whatever), is there?

One of the consequences of TCP being implemented in the Linux kernel is that companies were implicitly motivated to open source any performance or efficiency improvements to their TCP stack. Are any companies collaborating to improve QUIC efficiency issues in open source? The issues are well understood among at least the big cloud providers.

Quic is being standardized in the IETF there are a couple of companies involved:

- Cloudflare

- Facebook: They already use QUIC for some of their products, or at least it's a pretty sensitive piece of software on their architecture because they ask to report bugs to the bug bounty program[1]

- Microsoft

- Nginx

- Google

- NetApp

- Mozilla

- Traffic Server

- Litespeed

- Fastly

- F5

- Apple

Amazon is very quiet about all that, but they are probably looking into it. So, it is pretty backed up. If you take a look at their workgroup homepage (quicwg.org) you will see a couple of open source implementations, some from those same companies.

[1]: https://github.com/facebookincubator/mvfst/blob/master/READM...

And emerging QUIC acceleration technology is likely to be stifled by intellectual property laws.

Intel has already filed (in 2019) for a European patent that seems to claim inventorship of the generic concept of hardware offloading (as it applies to QUIC)

https://data.epo.org/publication-server/pdf-document?pn=3541...

Is this instance of a patent good or bad?

Bad, in my view. (Although I am not a lawyer, and would definitely appreciate input from one here!)

Hardware offload of a network protocol is an extremely generic concept and this patent seems to describe that concept (without any kind of novel mechanism or implementation details).

Bad, since it is an obvious idea that any engineer in the field could come up with.

Adoption of HTTP/2 also limits the appeal of QUIC. HTTP/2 delivers many (not all) of benefits QUIC offers and is both widely implemented and adopted now.