SRF TCP: A TCP-Friendly and Fair Congestion Control Method for High-Speed Networks

Decomposing RTT-unfairness in transport protocols

“…Our analysis in this section clearly illustrates that several aspects of TCP congestion-control contribute towards an RTT-based bias in throughput allocation-these include the window-growth in both Slow-start and Congestion-avoidance, as well as the use of a common initial window and a common Slow-start Threshold. Unfortunately, most attempts at alleviating RTT-unfairness focus only on the steady-state behavior of Congestion-avoidance [15], [16]. Clearly, in order to be truly RTT-fair, a congestion-control protocol would need to address each of these sources of bias.…”

“…All non-bottleneck links have a 1 Gbps capacity, and the values of RT T min for the different senders varies from 50ms to 500ms. We also use this topology for evaluating the fairness yielded by NewReno, SRF [16], and Libra [15]. We ensure that all transfers experience packet loss nearly simultaneously, by forcing packet drops in each of the transfers when the bottleneck buffers approach full-occupancy.…”

“…Thus, even when Alice and Bob have purchased the same Internet service plan from their local ISP, if Alice is downloading from a server that is twice as far away as Bob, the throughput of her download may be less than 20% of that of Bob! While some recent protocols attempt to reduce the degree of unfairness by adopting RTT-aware increase-factors [8], [10], [14], [15], [16], [17], empirical evaluations show that most of these simply reduce the degree of unfairness but do not yield truly fair throughput for finite transfers. In this paper, we attempt to understand why.…”

Rethinking the timescales at which congestion-control operates

“…This is because, primarily driven by the goal of not overloading the network, all previous protocols adopt two limiting design features: 1) Only a single (larger) sending rate is probed for over a round-trip time. This is true for all previous protocols, including recent ones, such as HighSpeed TCP, FAST, Scalable, CUBIC, and PCP [1], [2], [3], [4], [5], [6], [7]. This legacy design decision is perhaps motivated by the fact that unless the single rate is deemed acceptable (not too high), other rates should not be probed for.…”

“…As a result of these two design limitations, most protocolseven the recent ones designed for high-speed networks [2], [3], [4], [5], [6], [7]-take a fairly long time for converging to the avail-bw. For instance, Table I lists the experimentallyobserved times taken by a single transfer for acquiring an additional spare capacity of 1 Gbps that suddenly becomes available.…”