4 ms·

I hope we get in-kernel implementations of QUIC at some point because having to find a portable third-party library for userspace sounds about as appealing as

by nly 8y ago

I hope we get in-kernel implementations of QUIC at some point because having to find a portable third-party library for userspace sounds about as appealing as installing Winsock on Windows 95.

CharlesW 8y ago
I don't know much about this, so do you mind elaborating? Wouldn't userspace implementations be safer and easier to update as we spend the next few years sussing out security and performance issues?
- paulddraper 8y ago
  IDK about "safer", but they will be more numerous and harder to update. (It's not as simple as making sure your kernel is up-to-date.)
  - paulddraper 8y ago
    I am evidently wrong about something, but I'm not sure what.
ris 8y ago
But the whole point of QUIC is that it is a userspace implementation. From the QUIC viewpoint (and I take no sides in this) kernel implementation is death for a protocol because it freezes its specification and behaviour in slow-to-update systems. This is why they found they couldn't "just improve TCP".
- the8472 8y ago
  There have been plenty of improvements to TCP over time. New congestion controllers, new extension headers, fast open, ECN, etc.
  - netheril96 8y ago
    How long does each improvement achieve widespread adoption?
  - ris 8y ago
    I'm not saying that they don't happen, but they are extremely slow to gain traction because of various things including OS support.
- wpietri 8y ago
  Is that death for a protocol? Or success? I get why Google, which controls a great deal of the software on both ends of a very large number of connections, finds a settled standard inconvenient. But from my perspective, as somebody who uses Google software but does a lot of other things too, I like when we have standards that are implemented by many different people and aren't controlled by a single vendor that is eager to maintain or extend their large market shares in many areas. Can that be slow to change? Sure. But the speed is proportional to how much the change benefits people besides Google. Personally, I hope that QUIC is a first step toward taking the lessons learned and implementing them widely, rather than something that will evolve at a rapid pace precisely as long as Google needs it to and then stop.
- ldng 8y ago
  That is called a standard. You want it to settle down.
- josteink 8y ago
  > kernel implementation is death for a protocol because it freezes its specification and behaviour in slow-to-update systems Maybe that’s a matter of opinion, but I consider that to be a feature. I want protocols to remain stable, and not be subject to whatever whims-of-the-month the fruity people at Google LLC comes up with.
adrianmonk 8y ago
Existing HTTP is not in the kernel. If you want to speak HTTP, you already need a library. With existing HTTP, that library needs to handle portability concerns to use TCP on different operating systems. With new HTTP, the library will need to do the same thing but with UDP. Seems like the complexity is no higher, just a difference (TCP vs. UDP) in how your library will interface with the platform network stack API.
- dogma1138 8y ago
  Http is done in kernel on Windows http.sys is a kernel driver which IIS and some other windows servers use. Some UNIX distros also have their kernel implementation, and Linux has/had TUX but I’m not sure if it’s in use anywhere.
  - ComputerGuru 8y ago
    http.sys is strictly for listening for inbound connections and not a general purpose HTTP API. Amongst other things, it lets multiple applications listen to port 80 on Windows. Didn't read through this article the whole way, but it was the first I found to share that seemed to give a good overview: https://www.codeproject.com/articles/437733/demystify-http-sys-with-httpsysmanager https://www.codeproject.com/articles/437733/demystify-http-s...
    - dogma1138 8y ago
      Yes, http.sys is an http server implemented in the Windows Kernel it’s the http server IIS and all other http based windows services use and has an API for 3rd party servers. https://docs.microsoft.com/en-us/iis/get-started/introduction-to-iis/introduction-to-iis-architecture#hypertext-transfer-protocol-stack-httpsys https://docs.microsoft.com/en-us/iis/get-started/introductio... The point being that there are advantages to implementing a kernel or hybrid mode HTTP server and Microsoft has done it on Windows some other implementations exist but other than MF/Big Unix I’ve never seen them in actual use. I don’t think there is much of a point of implementing an HTTP client library in the kernel tho since the performance should be an issue really on the client side.

by nly 8y ago

I hope we get in-kernel implementations of QUIC at some point because having to find a portable third-party library for userspace sounds about as appealing as installing Winsock on Windows 95.

CharlesW 8y ago

I don't know much about this, so do you mind elaborating? Wouldn't userspace implementations be safer and easier to update as we spend the next few years sussing out security and performance issues?

paulddraper 8y ago
IDK about "safer", but they will be more numerous and harder to update. (It's not as simple as making sure your kernel is up-to-date.)
- paulddraper 8y ago
  I am evidently wrong about something, but I'm not sure what.

ris 8y ago

But the whole point of QUIC is that it is a userspace implementation. From the QUIC viewpoint (and I take no sides in this) kernel implementation is death for a protocol because it freezes its specification and behaviour in slow-to-update systems. This is why they found they couldn't "just improve TCP".

the8472 8y ago
There have been plenty of improvements to TCP over time. New congestion controllers, new extension headers, fast open, ECN, etc.
- netheril96 8y ago
  How long does each improvement achieve widespread adoption?
- ris 8y ago
  I'm not saying that they don't happen, but they are extremely slow to gain traction because of various things including OS support.
wpietri 8y ago
Is that death for a protocol? Or success? I get why Google, which controls a great deal of the software on both ends of a very large number of connections, finds a settled standard inconvenient. But from my perspective, as somebody who uses Google software but does a lot of other things too, I like when we have standards that are implemented by many different people and aren't controlled by a single vendor that is eager to maintain or extend their large market shares in many areas. Can that be slow to change? Sure. But the speed is proportional to how much the change benefits people besides Google. Personally, I hope that QUIC is a first step toward taking the lessons learned and implementing them widely, rather than something that will evolve at a rapid pace precisely as long as Google needs it to and then stop.
ldng 8y ago
That is called a standard. You want it to settle down.
josteink 8y ago
> kernel implementation is death for a protocol because it freezes its specification and behaviour in slow-to-update systems Maybe that’s a matter of opinion, but I consider that to be a feature. I want protocols to remain stable, and not be subject to whatever whims-of-the-month the fruity people at Google LLC comes up with.

adrianmonk 8y ago

Existing HTTP is not in the kernel. If you want to speak HTTP, you already need a library. With existing HTTP, that library needs to handle portability concerns to use TCP on different operating systems. With new HTTP, the library will need to do the same thing but with UDP. Seems like the complexity is no higher, just a difference (TCP vs. UDP) in how your library will interface with the platform network stack API.

dogma1138 8y ago
Http is done in kernel on Windows http.sys is a kernel driver which IIS and some other windows servers use. Some UNIX distros also have their kernel implementation, and Linux has/had TUX but I’m not sure if it’s in use anywhere.
- ComputerGuru 8y ago
  http.sys is strictly for listening for inbound connections and not a general purpose HTTP API. Amongst other things, it lets multiple applications listen to port 80 on Windows. Didn't read through this article the whole way, but it was the first I found to share that seemed to give a good overview: https://www.codeproject.com/articles/437733/demystify-http-sys-with-httpsysmanager https://www.codeproject.com/articles/437733/demystify-http-s...
  - dogma1138 8y ago
    Yes, http.sys is an http server implemented in the Windows Kernel it’s the http server IIS and all other http based windows services use and has an API for 3rd party servers. https://docs.microsoft.com/en-us/iis/get-started/introduction-to-iis/introduction-to-iis-architecture#hypertext-transfer-protocol-stack-httpsys https://docs.microsoft.com/en-us/iis/get-started/introductio... The point being that there are advantages to implementing a kernel or hybrid mode HTTP server and Microsoft has done it on Windows some other implementations exist but other than MF/Big Unix I’ve never seen them in actual use. I don’t think there is much of a point of implementing an HTTP client library in the kernel tho since the performance should be an issue really on the client side.