Fixing the unfairness of TCP congestion control
A recent article discusses an issue with the current TCP algorithm.
In a nutshell, a single TCP session tends to share bandwidth with other TCP sessions in a network in a reasonably fair fashion. Not perfectly fair but reasonably fair.
However if a single host runs multiple TCP sessions simultaneously between itself and one or more servers, that host may exceed its “fair” share of bandwidth. This practice is common for peer-to-peer protocols, as the more sessions a downloader opens, the better their typical performance.
Thus, since the fairness of TCP is based on the granularity of the session, opening more sessions allows a host to grab an “unfair” portion of network capacity. This is particularly an issue in last mile networks where dozens of hosts share a limited-capacity pipe.
It seems as if there is a fairly simple way for last mile providers to resolve the issue: do traffic shaping at the host level or physical port level. A simple token bucket algorithm or weighted fair queuing would likely do the trick, dropping packets so that hosts are forced to share bandwidth fairly, while allowing them to use more than their “fair” share when the network has spare capacity. This mechanism would effective ignore TCP, as it would work on layer 2 or layer 3, and would not require a change to the delicate TCP congestion control algorithm.
However, the article describes a proposal that eschews simple traffic shaping and instead proposes to change TCP. While the details will be published next month, at a high level this seems like a very bad idea.
Changing TCP will require an upgrade to all hosts. With an installed based of hundreds of millions of hosts, TCP will take years to effectively upgrade. For example, will Microsoft support such a change to Windows XP to do this, when they are trying to obsolete that operating system? Additionally, end users will not be motivated to upgrade as it will slow their performance, while early adopters will be punished.
Fairness is not a layer 4 problem. It is a layer 2 or 3 problem. Trying to solve it at layer 4 will be expensive and ineffective.