4 ms·

You're right, I misstated that the order-of-magnitude was a built-in variable, thanks. Still, if that assumption IS a built-in variable, then the three basic v

You're right, I misstated that the order-of-magnitude was a built-in variable, thanks. Still, if that assumption IS a built-in variable, then the three basic variants I listed would cover an awful lot of use cases. I'm thinking of this from the POV of an operating system vendor. Like all software components, the supplied options which can be configured or tuned meet the vast majority of customer needs. Those who need (or think they need) something above that generally have the nouse to run their own code and support it themselves. Assuming most CDNs and streamers run Linux and do want support, you could make the internet massively faster just by getting a fairly relaxed single RemyCC into the upstream Linux kernel, then backported into vendor kernels (Red Hat, SuSE, Canonical, etc). Then you just need mindshare from the CDNs that their sysadmins will set "net.ipv4.tcp_congestion_control = remy" I'm not saying it's ideal but I am saying it's an improvement over the current state of things.

donavanm 12y ago
Actually, I think it is applicable to those large scale senders today. As you point out they generally don't rely on upstream improvemnts for areas like this. Even if it is a dozen different variant algorithms that need to be supported that's an entirely tractable problem. The contention would be if remy variants can outperform existing algorithms which themselves have tunable inputs like initcwnd srtt/rttvar mss pacing window size etc.
- suprjami 12y ago
  You touch on an interesting concept, making a congestion algorithm which is fully tunable. Maybe then the job of calculating the optimal tunables could be moved out to a daemon which does Remy-like simulations to keep the algorithm in optimal state. Obviously we don't yet have the compute power to do that as effectively as Remy in real-time.

donavanm 12y ago

Actually, I think it is applicable to those large scale senders today. As you point out they generally don't rely on upstream improvemnts for areas like this. Even if it is a dozen different variant algorithms that need to be supported that's an entirely tractable problem. The contention would be if remy variants can outperform existing algorithms which themselves have tunable inputs like initcwnd srtt/rttvar mss pacing window size etc.

suprjami 12y ago
You touch on an interesting concept, making a congestion algorithm which is fully tunable. Maybe then the job of calculating the optimal tunables could be moved out to a daemon which does Remy-like simulations to keep the algorithm in optimal state. Obviously we don't yet have the compute power to do that as effectively as Remy in real-time.