7 ms·
Quic is a great protocol but IIUC you have to apply a user space library for things that normally (TCP) is kernel/hardware. Well, at least in my own experiments
by klabb3 4y ago
Quic is a great protocol but IIUC you have to apply a user space library for things that normally (TCP) is kernel/hardware. Well, at least in my own experiments with a Golang implementation, I've seen CPU be the bottleneck for high bandwidth transfers (MTU is ~1300b). Add to that that common OS:s don't give you a particularly large UDP receive buffer, which can cause a BDP bottleneck for high latency connections.
- JoshTriplett 4y agoThere's no fundamental reason quic couldn't happen in kernel-space, it just hasn't been done yet.
- SquareWheel 4y agoThat's true, and maybe lower-level optimizations will start to emerge. But I suspect QUIC was intentionally left in userspace to allow for more rapid development. Indeed there are already many libraries available which means you can use it today. If we had to wait for kernels and middleware to support it, that might still be years out.
- JoshTriplett 4y agoI agree, and I think userspace development was a good idea. I also don't think it needs to stay in userspace forever. In particular, ideally we'll have kernel support that allows for more capable userspace stacks to run, and also allows just opening a socket.
- stiglitz 4y agoMsquic can be built as a driver. https://github.com/microsoft/msquic/blob/main/msquic.kernel.sln https://github.com/microsoft/msquic/blob/main/msquic.kernel....