4 ms·
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?
by bayindirh 1y ago
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 1y ago> 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 1y ago> 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 1y agoFortunately 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 1y ago> 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 1y agoNo, 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 1y ago"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 1y agoWhat do you mean by "other applications"?
- jeffbee 1y agoI 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 1y agoAh, but that's an OS implementation problem, not one with TCP or QUIC, no?
- jeffbee 1y agoSure, 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.