<story><title>Remy – Computer-generated TCP congestion algorithm</title><url>http://web.mit.edu/remy/</url></story><parent_chain></parent_chain><comment><author>donavanm</author><text>A key point that&amp;#x27;s glossed over is computational complexity on the senders side. The existing congestion &amp;amp; flow control mechanisms are quite simple. In contrast these &amp;quot;algorithms have more than 150 rules.&amp;quot; Additional state and computation time on the sender side is non trivial when managing tens or hundreds of thousands of concurrent flows.&lt;p&gt;These algorithms vary based on link&amp;#x2F;endpoint characteristics. This would require a priori knowledge of the path &amp;amp; quality to each TCP receiver in order to select an appropriate congestion control algorithm. This problem is probably tractable for large scale implementations. The number of unique networks an endpoint is exposed to is in the few million range, and roughly stable over time. Collapsing adjacent and similar networks would get down in to the tens of thousands of variant prefixes.&lt;p&gt;The characteristics of each prefix are roughly stable over time; a subnet of consumer cable endpoints does not flip to become a CDMA mobile subnet. At a guess the rate of change is 1-5% per day. If you can track the performance of millions of subnets a 1% delta per day is certainly feasible. In practice any single sender would need dozens, or hundreds, of different congestion control variants.&lt;p&gt;And lastly they appear to simulate receivers with similar network characteristics on a single contended link. In practice receivers will have wildly different characteristics. Traffic to mobile, consumer fixed line isp, and datacenter networks will all travel on common transit carriers. Additionally even a single IP endpoint can have variable hidden receivers; think 802.11, gbe, embedded clients, and a desktop OS behind a consumer NAT device. Now the sender must track, and adapt, congestion control &lt;i&gt;per flow&lt;/i&gt;.&lt;p&gt;In summary synthetic testing of a simplistic use case has out performed generalized solutions. This should surprise no one. The details of practical implementation are ignored, and significant.</text></comment>
<story><title>Remy – Computer-generated TCP congestion algorithm</title><url>http://web.mit.edu/remy/</url></story><parent_chain></parent_chain><comment><author>contingencies</author><text>Wow, this looks pretty impressive.&lt;p&gt;My general understanding is that congestion control algorithms seek to provide performance and efficiency in end to end TCP (transport-layer) connections that are well-matched to the underlying network path characteristics (latency, throughput, lossiness). Unfortunately, obtaining reliable information about these characteristics can be difficult, and this is particularly the case with dynamic paths (IP mobility, mobile while moving between congested&amp;#x2F;non-congested cells, shared near-capacity networks, etc.).&lt;p&gt;Previously, the areas in which customizing these sorts of algorithms has yielded particularly high returns have been satellite communications and other extremely long distance&amp;#x2F;high latency&amp;#x2F;known characteristic deployments with outlying or extreme properties.&lt;p&gt;My main two questions would then be: (1) To what range of network layer path or individual link-layer characteristics do the claimed benefits of this algorithm apply? (2) How much difference will this make to mobile access or IPv6 IP mobility under a range of different realistic network link issue scenarios?&lt;p&gt;If the claims in this paper are true (broadly applicable increase in throughput and fairness) then I suppose we&amp;#x27;ll see a switch to this algorithm en-masse, thus providing another handy covert operating system detection mechanism to delimit the new generation of kernels.</text></comment>