4 ms·

> and takes control away from the operating system That's just because QUIC is a new, not yet specified protocol, isn't it? Kernels will get support eventuall

> and takes control away from the operating system That's just because QUIC is a new, not yet specified protocol, isn't it? Kernels will get support eventually. Microsoft is actually already shipping some code. [1] Browsers will probably switch to OS facilities once they are mature enough and provide a performance benefit. [1] https://www.windowslatest.com/2018/04/03/microsoft-to-add-support-for-googles-quic-fast-internet-protocol-in-windows-10-redstone-5/ https://www.windowslatest.com/2018/04/03/microsoft-to-add-su...

jeffbee 6y ago
It's not abundantly clear that there can be a performance benefit from moving QUIC into the kernel. Indeed, there is no performance benefit from having TCP in the kernel. That's why one of the most common tactics in high-performance networking is to move the TCP stack into userspace. The end-to-end argument in IP networking evolved in a time (the 1970s and 1980s) when a host could reasonably be considered the endpoint. Now hosts are so big and powerful that it's no longer reasonable to draw the boundary around them. The individual process running on the host is the true endpoint, and having the application in charge of its own network flow control is the natural evolution of things.
- the_duke 6y ago
  > Indeed, there is no performance benefit from having TCP in the kernel. That's why one of the most common tactics in high-performance networking is to move the TCP stack into userspace. But a userspace network stack only make sense in single purpose devices/servers, because they have to take over the hardware, right? On a consumer device many applications can use the network concurrently. QUIC runs on top of UDP anyway, so userspace libraries use OS UDP facilities, but lose the ability to do better cross-application balancing. Hardware TCP offloading also plays a role of course.
  - jeffbee 6y ago
    You don't have to take over the hardware to do userspace TCP. You only need the ability to put raw datagrams on the wire (Linux RAW socket, for example). You _can_ take over the device with something like DPDK but that's not necessary. As you correctly say, QUIC uses existing OS-level facilities to communicate over UDP, so there is no reason that several processes on a single host cannot use application-level QUIC stacks concurrently.
  - JoshTriplett 6y ago
    It's possible to use kernel facilities to route flows to the right application or stack, and then use that stack to process individual connections. For example, many network cards support creating multiple virtual network devices, and you could hand a whole such device to a userspace process, but only let it see traffic intended for that device. Or, finer-grained, you could use a filter to steer certain packet flows to a process, while handling others in the kernel. I do absolutely think there's value in having native QUIC in the kernel, but then, I also think there's value in having native TLS in the kernel; doesn't mean you always want to use it.

jeffbee 6y ago

It's not abundantly clear that there can be a performance benefit from moving QUIC into the kernel. Indeed, there is no performance benefit from having TCP in the kernel. That's why one of the most common tactics in high-performance networking is to move the TCP stack into userspace. The end-to-end argument in IP networking evolved in a time (the 1970s and 1980s) when a host could reasonably be considered the endpoint. Now hosts are so big and powerful that it's no longer reasonable to draw the boundary around them. The individual process running on the host is the true endpoint, and having the application in charge of its own network flow control is the natural evolution of things.

the_duke 6y ago
> Indeed, there is no performance benefit from having TCP in the kernel. That's why one of the most common tactics in high-performance networking is to move the TCP stack into userspace. But a userspace network stack only make sense in single purpose devices/servers, because they have to take over the hardware, right? On a consumer device many applications can use the network concurrently. QUIC runs on top of UDP anyway, so userspace libraries use OS UDP facilities, but lose the ability to do better cross-application balancing. Hardware TCP offloading also plays a role of course.
- jeffbee 6y ago
  You don't have to take over the hardware to do userspace TCP. You only need the ability to put raw datagrams on the wire (Linux RAW socket, for example). You _can_ take over the device with something like DPDK but that's not necessary. As you correctly say, QUIC uses existing OS-level facilities to communicate over UDP, so there is no reason that several processes on a single host cannot use application-level QUIC stacks concurrently.
- JoshTriplett 6y ago
  It's possible to use kernel facilities to route flows to the right application or stack, and then use that stack to process individual connections. For example, many network cards support creating multiple virtual network devices, and you could hand a whole such device to a userspace process, but only let it see traffic intended for that device. Or, finer-grained, you could use a filter to steer certain packet flows to a process, while handling others in the kernel. I do absolutely think there's value in having native QUIC in the kernel, but then, I also think there's value in having native TLS in the kernel; doesn't mean you always want to use it.