Performance of Competing High-Speed TCP Flows

M.C. Weigle, P. Sharma, and J. Freeman, Performance of Competing High-Speed TCP Flows, Proceedings of NETWORKING, Coimbra, Portugal, May 2006, pp. 476-487.

Abstract

The goal of recent high-speed TCP implementations is to allow scientists who have access to new high-speed networks to efficiently transfer large datasets to their remote colleagues. As of yet, there is no "standard" high-speed TCP implementation. Because of this, scientists using one high-speed protocol may find themselves sharing a link with scientists using a different high-speed protocol. Previous work has evaluated inter-protocol performance, but only with both flows starting at the same time -- an unlikely situation. We perform an evaluation study using ns-2 to investigate the performance of competing high-speed TCP flows where one flow enters a network in which another high-speed flow has already reached its maximum data rate. The fairest result would be for the existing flow to cede half of its bandwidth to the new flow in order to allow both flows to evenly share the link. Our results show that in most cases this does not happen, but rather one high-speed flow dominates the other. Surprisingly, it is not always the existing flow that dominates.

ns-2 Modifications

• SACK-TS - from North Carolina State
• BIC-TCP, CUBIC, HS-TCP, S-TCP, H-TCP in ns-2 - from North Carolina State
  (updated link - Jan 2009)
• TCP FAST in ns-2 - from University of Melbourne

• For all variants except FAST, TCP SACK-TS is used as the error recovery mechanism.
• The ns-2 FAST implementation uses standard TCP SACK error recovery.
• In all experiments, we use Limited Slow-Start, which limits the exponential growth of the congestion window during slow-start when w > max_ssthresh. Doubling a very large congestion window in one RTT could cause a burst of segments to be sent and increase the likelihood that many of the segments would be lost. As is recommended, we set max_ssthresh to 100 segments.
• In ns-2, the maxburst parameter controls the maximum number of segments that can be sent in response to a single ACK. We set maxburst to 2 segments.
• We set the ns-2 overhead_ parameter to 8 microseconds to avoid phase effects. This causes a sender to delay a random amount of time before each send operation.

High-Speed Protocol Settings

• HS-TCP: LowWindow = 38 segments
• Scalable TCP: LowWindow = 16 segments
• FAST: alpha = 312
  The implementors of FAST in ns-2 recommend setting alpha such that alpha/C is greater than 5*mithresh, where C is the bottleneck speed in packets/ms and mithresh is the threshold of queuing delay that controls when FAST enters its multiplicative increase phase (set by default to 0.75 ms). With a 622 Mbps bottleneck, the link speed is 78 1000-byte packets/ms, so we set alpha to 4C, or 312 packets. This results in alpha/C = 4 ms, which is greater than 5*0.75=3.75 ms.
• H-TCP: DeltaL = 1 second, 0.5 < beta < 0.8
• BIC-TCP: Smax = 32, Smin = 0.01, beta = 0.125
• CUBIC: beta = 0.8, C = 0.4, Wmax = 160

• hstcp.tcl
• utils.tcl - used by hstcp.tcl

• process-hstcp-250s
  Used by process-hstcp-250s:
  • avgc250-500.awk - compute avg cwnd
  • avgt250-500.awk - compute avg tput