3 ms·

> To put this into simple terms, you could write a RemyCC for a 1Gbps 10ms link, and that RemyCC would still perform better (than other CC algos) through a rang

> To put this into simple terms, you could write a RemyCC for a 1Gbps 10ms link, and that RemyCC would still perform better (than other CC algos) through a range of 100Mbps to 10Gbps, and 1ms to 100ms. No, pg 133 of the paper. They accept design time input variables as a range, differing by an order of magnitude. If the "assumptions aren’t met, performance deteriorates." Throughput and delay look horrendous when the actual characteristics dont match the model. > That being said, implementing a few pre-baked RemyCCs in major operating systems surely would help. Say you had a mobile" (5Mbps 500ms) and "home broadband" (50Mbps 50ms) and "LAN" (1Gbps 5ms) RemyCC available in Lin/Mac/Win/And/IOS, TCP performance would be several times better than what we have today. I'm also dubious of any actual adoption. However I believe youre underestimating the number of variant algorithms required. The consumer endpoints receive the vast bulk of the traffic, and are rarely contended on transmit. Its the large scale deployments of senders (CDNs, Streaming Services, etc) that would make a significant impact to global throughput.

keithwinstein 12y ago
You're totally correct that the performance is terrible when the actual network characteristics are something that the algorithm's "prior assumptions" thought was impossible. We think the same is true of traditional TCP. (For example, traditional TCP assumes that in-network buffers will be small, and therefore that it's acceptable to keep filling them until they start dropping packets, without harming delay-sensitive cross traffic too much. Today's Internet no longer matches TCP's implicit model, and the consequences are that you can't upload to YouTube and use Skype at the same time on a consumer Internet connection. We think it's better to at least make the assumptions explicit!) In the second paper (now posted), we have improved the initial results in that we can now train a RemyCC that outperforms TCP CUBIC-over-sfqCoDel over a 1000-fold range of link rates (instead of 10x in the first paper). But the same basic point still holds.
- dtaht 12y ago
  My problem with the new paper is that it computes for a baseline rtt of 100 or 150ms. Real world average rtts are in the range of 4 ms for Google fiber 18 ms for fios and 38 ms for cable, with the ethernet rtt in a Datacenter far lower than that. I would be very happy to see Remy produce a CC for these rtts one day also.
  - keithwinstein 12y ago
    Stay tuned... or bug Anirudh for a sneak preview when you see him at SIGCOMM. (Hi Dave!)
    - dtaht 12y ago
      I put up all I have to say on the subject at: https://lists.bufferbloat.net/pipermail/bloat/2014-August/002045.html https://lists.bufferbloat.net/pipermail/bloat/2014-August/00...
- yxhuvud 12y ago
  Would it be possible to have an external monitor that detects what assumptions is holding? (and either recomputate the algorithm or change to one that is working)?
suprjami 12y ago
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.

keithwinstein 12y ago

You're totally correct that the performance is terrible when the actual network characteristics are something that the algorithm's "prior assumptions" thought was impossible. We think the same is true of traditional TCP. (For example, traditional TCP assumes that in-network buffers will be small, and therefore that it's acceptable to keep filling them until they start dropping packets, without harming delay-sensitive cross traffic too much. Today's Internet no longer matches TCP's implicit model, and the consequences are that you can't upload to YouTube and use Skype at the same time on a consumer Internet connection. We think it's better to at least make the assumptions explicit!) In the second paper (now posted), we have improved the initial results in that we can now train a RemyCC that outperforms TCP CUBIC-over-sfqCoDel over a 1000-fold range of link rates (instead of 10x in the first paper). But the same basic point still holds.

dtaht 12y ago
My problem with the new paper is that it computes for a baseline rtt of 100 or 150ms. Real world average rtts are in the range of 4 ms for Google fiber 18 ms for fios and 38 ms for cable, with the ethernet rtt in a Datacenter far lower than that. I would be very happy to see Remy produce a CC for these rtts one day also.
- keithwinstein 12y ago
  Stay tuned... or bug Anirudh for a sneak preview when you see him at SIGCOMM. (Hi Dave!)
  - dtaht 12y ago
    I put up all I have to say on the subject at: https://lists.bufferbloat.net/pipermail/bloat/2014-August/002045.html https://lists.bufferbloat.net/pipermail/bloat/2014-August/00...
yxhuvud 12y ago
Would it be possible to have an external monitor that detects what assumptions is holding? (and either recomputate the algorithm or change to one that is working)?

suprjami 12y ago

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.