mjoras

3 ms·

1.
by mjoras 6y ago
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
2.
by mjoras 6y ago
Policy reasons is all I can say unfortunately.
3.
by mjoras 6y ago
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.
4.
by mjoras 6y ago
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.
5.
by mjoras 6y ago
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
6.
by mjoras 6y ago
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.
7.
by mjoras 6y ago
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.
8.
by mjoras 6y ago
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
9.
by mjoras 8y ago
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