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