4 ms·

> (1) To what range of network layer path or individual link-layer characteristics do the claimed benefits of this algorithm apply? The paper states their Remy

> (1) To what range of network layer path or individual link-layer characteristics do the claimed benefits of this algorithm apply? The paper states their RemyCC outperformed currently-available CCs even when link variables varied by an order of magnitude. 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. > (2) How much difference will this make to mobile access or IPv6 IP mobility under a range of different realistic network link issue scenarios? The whole premise of the paper is that a well-written RemyCC would probably handle such situations better than a traditional congestion control algorithm. > then I suppose we'll see a switch to this algorithm en-masse You are more optimistic than I. Several people have already solved bufferbloat in theory, but it still exists in real life. Updating legacy devices, even with something as "simple" as a TCP congestion control module, may not be possible. 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.

donavanm 12y ago
> 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)?

donavanm 12y ago

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