Thanks for these comments! Humans have been designing congestion-control schemes for 30 years; what's interesting about our work is that we are starting to lea

Thanks for these comments! Humans have been designing congestion-control schemes for 30 years; what's interesting about our work is that we are starting to learn how to teach a computer to do the same thing from first principles. (And then learning from what the computer comes up with to inform human designs...) I can't tell you yet exactly how computationally taxing the computer-generated algorithms will turn out to be, compared with TCP CUBIC or similar. So far we've found that because the RemyCC's rules are just dumb lookups into a precalculated lookup table, the CPU requirements are pretty mild. But we need to play around with RemyCCs a lot more before I can speak more confidently. We're close but not there yet. To your other point about whether the algorithms "vary based on link/endpoint characteristics" -- I don't think they will have to. Quantitatively, a single RemyCC has been able to outperform TCP CUBIC over a thousand-fold range of link rates, and with similar results for ranges of latencies, etc. Just as servers currently use a single TCP congestion-control scheme (often CUBIC) to talk to many different clients over diverse network paths, there's no particular reason you wouldn't use a single computer-generated algorithm to do the same. Trying to "learn" different parameters for different ranges of remote IP addresses is an interesting idea, but not one we have explored or are proposing.