[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"!

[lxgr]

No, congestion control in the network sense is about congestion at choke points in packet networks due to higher inflow than outflow rates.

While you're still on your own host, your OS has complete visibility into which applications are currently intending to send data and can schedule them much more directly.

[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?

[jeffbee]

Sure, but the ready appeal of QUIC is that it is in user space by nature, while Linux ties TCP to the kernel. You either need special privileges to run user space TCP on Linux, or you need a different operating system kernel altogether.