[nickysielicki]

> Running in user space offers more flexibility for resource management and experimentation.

I stopped reading here. This isn’t really an essential property of QUIC, there’s a lot of good reasons to eventually try to implement this in the kernel.

https://lwn.net/Articles/1029851/

[lxgr]

Maybe not an essential property of QUIC, but definitely one of not using TCP.

Most OSes don't let you send raw TCP segments without superuser privileges, so you can't just bring your own TCP congestion control algorithm in the userspace, unless you also wrap your custom TCP segments in UDP.

[bayindirh]

Why do the hard work if the same thing can be done by the kernel, or even by the card itself?

Drown other applications for your own benefit?

[lxgr]

> Why do the hard work if the same thing can be done by the kernel, or even by the card itself?

How would you swap out the TCP congestion control algorithm in an OS, or even hardware, you don't control?

> Drown other applications for your own benefit?

Fairness equivalent to classic TCP is a design goal of practically all alternative algorithms, so I'm not sure what you're implying.

It's entirely possible to improve responsivity without compromising on fairness, as e.g. BBR has shown.

[neilalexander]

> How would you swap out the TCP congestion control algorithm in an OS, or even hardware, you don't control?

On the contrary, introducing their own novel/mysterious/poorly implemented congestion control algorithms is not a thing I want userspace applications doing.

[lxgr]

Fortunately you don't get any say in what my userspace applications do on my own hardware.

And if you worry about hostile applications on your own hardware, the OS is an excellent point to limit what they can do – including overwhelming your network interface.

[neilalexander]

> the OS is an excellent point to limit what they can do – including overwhelming your network interface

One might even call this "congestion control"!

[jeffbee]

"Drown other applications" is unfortunately exactly what happens when you let the Linux kernel run your TCP stack. Profile your application and you may discover that your CPUs are being spent running the protocol stack on behalf of other applications.

[lxgr]

What do you mean by "other applications"?

[jeffbee]

I mean when your application sends on a socket, the kernel may also send and receive traffic for another task while it's in the syscall, just for funsies, and this is true even if your applications are containerized and you believe their CPU cores are dedicated to the container.

[lxgr]

Ah, but that's an OS implementation problem, not one with TCP or QUIC, no?