> One thing I don't understand is, if it's encrypted, we'll never see hardware accelerated QUIC ?

I think parts of it can still be hardware-accelerated. For example, OpenSSL et al will take advantage of available AES encryption CPU instructions, if it knows about them. So, if the TLS library supports such offloading, then the HTTP/3 library would get that benefit.

> I've read it's 2 to 3 times more CPU intensive, aren't we implicitly giving an artificial competitive advantage to the "Cloud" ? By the "Cloud" I mean big provider with like (obviously) Google, Cloudflare, Akamaï ...

Happily, a number of those vendors are kernel developers, and contribute changes back upstream. So, if the bottleneck is in the kernel (for example, by a lack of UDP fast processing paths), then I expect those cloud providers would be working on contributions to make kernel UDP as performant as kernel TCP.

The next thing that would be missing is support for UDP offloading in the NIC space. But TBH I don't know much about the current state of hardware offloading, so I can't speak to it.

> Isn't TCP already versioned ?

I was curious about this, so I looked it up, and I don't think it is. IP is certainly versioned (IPv4 vs. IPv6), but looking at the list of protocol numbers[0], I only see one entry for TCP. And I don't see anything that looks obviously like 'TCPv2'.

[0]: https://www.iana.org/assignments/protocol-numbers/protocol-n...

> > Isn't TCP already versioned ?

> I was curious about this, so I looked it up, and I don't think it is. IP is certainly versioned (IPv4 vs. IPv6), but looking at the list of protocol numbers[0], I only see one entry for TCP. And I don't see anything that looks obviously like 'TCPv2'.

Currently there is only a single TCP, it didn't need new version, because it has options mechanism to add additional information as needed. If it would need to be redesigned a new protocol would be created and a new protocol number would be allocated. Kind of like what happened with ICMP and ICMPv6.

Hum, right, parts of TLS could be offloaded. Now will the TLS protocol will continue to evolve ? And will QUIC follow ?

And you could offload UDP, TLS but not QUIC itself. Unless you're BigBuck Company and offload to FPGAs competition can't afford. Could happen.

It's a gap that might close, but right now, to me, it is a notable competitive advantage.

I'm not sure there's a reason large parts of it couldn't be hardware accelerated.. for that matter why specific implementations couldn't happen on a network controller for that matter. Sure, initial implementations will be software only, so that it can be implemented on top of the OS, that doesn't negate the opportunity to move pieces down the stack.

Some NICs already accelerate TLS so QUIC probably won't be any more difficult. Although QUIC NICs may not be available until 2-3 years after the RFC.