4 ms·

QUIC needs a kernel implementation. At least in Linux, TCP/IP does a lot of its processing in soft interrupt handlers which is far cheaper and more responsive

by ppg677 5y ago

QUIC needs a kernel implementation. At least in Linux, TCP/IP does a lot of its processing in soft interrupt handlers which is far cheaper and more responsive to pre-empt compared to UDP packet delivery and wakeup to an application thread. You don't want your transport acknowledgement packets to get delayed/lost because of app thread scheduling.

fulafel 5y ago
This argument would benefit from quantitavie evidence showing impact on end2end application performance or server load.
- ppg677 5y ago
  It is way less CPU efficient, with poor tail latency for LAN environments.
qalmakka 5y ago
It would also be great to have a standard API to create QUIC sockets, like BSD sockets on POSIX. It would make easy to swap implementations and port applications using QUIC to other systems, avoiding balcanization. I can see OSes integrating QUIC in their system libraries, and it would be great to avoid dozens of #ifdefs or relying on third party libraries.
Klasiaster 5y ago
You have to consider that an in-kernel implementation also hinders innovation - for example, things like BBR instead of Cubic/NewReno can be rolled out easily in userspace through the application's QUIC library while it takes a while until all clients and servers a) use a recent kernel which has TCP BBR support and b) have it configured by default.
- Klasiaster 5y ago
  … and another bonus is that your QUIC implementation can be in a memory safe language and doesn't have to use C ;)
drewg123 5y ago
I work on kernel and network performance on FreeBSD. For me the issue with QUIC is that we loose a few decades of optimizations in software and hardware. Eg, we loose TCP TSO and LRO (which reduce trips through the network stack, and thus per-byte overhead costs), and we loose inline crypto offload (which offloads the CPU and cuts memory bandwidth in half). So this makes QUIC roughly 3-4x as expensive in terms of CPU and memory bandwidth as opposed to TLS over TCP.
- ppg677 5y ago
  Great points.
MayeulC 5y ago
Could this get implemented in userspace with BPF used to offload some processing in kernel space? Could this be implemented in an unprivileged process?

by ppg677 5y ago

fulafel 5y ago

This argument would benefit from quantitavie evidence showing impact on end2end application performance or server load.

ppg677 5y ago
It is way less CPU efficient, with poor tail latency for LAN environments.

qalmakka 5y ago

It would also be great to have a standard API to create QUIC sockets, like BSD sockets on POSIX. It would make easy to swap implementations and port applications using QUIC to other systems, avoiding balcanization. I can see OSes integrating QUIC in their system libraries, and it would be great to avoid dozens of #ifdefs or relying on third party libraries.

Klasiaster 5y ago

You have to consider that an in-kernel implementation also hinders innovation - for example, things like BBR instead of Cubic/NewReno can be rolled out easily in userspace through the application's QUIC library while it takes a while until all clients and servers a) use a recent kernel which has TCP BBR support and b) have it configured by default.

Klasiaster 5y ago
… and another bonus is that your QUIC implementation can be in a memory safe language and doesn't have to use C ;)

drewg123 5y ago

I work on kernel and network performance on FreeBSD. For me the issue with QUIC is that we loose a few decades of optimizations in software and hardware. Eg, we loose TCP TSO and LRO (which reduce trips through the network stack, and thus per-byte overhead costs), and we loose inline crypto offload (which offloads the CPU and cuts memory bandwidth in half). So this makes QUIC roughly 3-4x as expensive in terms of CPU and memory bandwidth as opposed to TLS over TCP.

ppg677 5y ago
Great points.

MayeulC 5y ago

Could this get implemented in userspace with BPF used to offload some processing in kernel space? Could this be implemented in an unprivileged process?