Hacker News Reader

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.

View on HN

There's no fundamental reason quic couldn't happen in kernel-space, it just hasn't been done yet.

That'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.

I 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.

Msquic can be built as a driver. https://github.com/microsoft/msquic/blob/main/msquic.kernel....

Reply on news.ycombinator.com