TCP sometimes gets a bad rap because of the way its congestion-control algorithm hunts for bandwidth haphazardly and backs off conservatively at any sign of congestion. A properly tuned TCP implementation running over a well-engineered network can readily achieve throughputs of up to 100M bit/sec, even with very high latencies. But beyond 100M bit/sec in a typical high-latency environment, performance starts to degrade.
However, there is an elegant and easily implemented fix in a protocol enhancement called High-speed TCP (HS-TCP ). HS-TCP is an update of TCP that reacts better when using large congestion windows on high-bandwidth, high-latency networks.
Documented in IETF RFC-3649 , HS-TCP has experimental status rather than being on a standards track. Nevertheless, it is stable and useful, and is likely to be incorporated into future standards - just as with previous successful experimental modifications to TCP.
A window into the problem
TCP allows applications to communicate reliably over unreliable IP packet networks and permits sharing of network bandwidth across connections in a roughly fair fashion. It does so by having each TCP sender dynamically adjust its transmission window, which represents the maximum amount of unacknowledged data that can be in transit in the network at any given time.
The reason TCP performance starts to degrade beyond 100M bit/sec has to do with the window-adjustment algorithm. In its congestion-avoidance phase, ordinary TCP increases its sending window by one packet every round-trip time. And when it detects congestion, it cuts the window in half. For a high-bandwidth, high-latency connection, which is called a long fat network or LFN, the optimal window size might be 8,000 packets or more. This means it takes 4,000 round trips to recover from congestion. If each round-trip takes 100 millisec, the recovery time is 400 seconds. In a highly dynamic network, with lots of connections coming and going, normal TCP is simply too sluggish to track all of the activity.
HS-TCP alters how the window is opened on each round trip and closed on congestion events as a function of the absolute size of the window. When the window is small, HS-TCP behaves exactly like ordinary TCP. But when the window is large, it increases the window by a larger amount and decreases it by a smaller amount, where these amounts are chosen based on the precise value of the window in operation. The effect of these changes is that ordinary TCP's sluggishness disappears. HS-TCP performs well in LFNs and enables full utilization of multi-gigabit, high-delay links.
The smaller decrease and larger increase in window size mean that HS-TCP recovers faster than ordinary TCP, often by orders of magnitude. Not only does this approach enable full utilization of high-speed WAN links, but it does so without losing or compromising any of the familiar and essential benefits of TCP.
This approach works properly even when HS-TCP connections share WAN links with ordinary TCP connections. A single HS-TCP connection has approximately the same congestion control behavior as a number of ordinary TCP connections, with the number of "virtual connections" increasing with the size of the window. Some non-TCP schemes for LFNs are not TCP-friendly and can clobber ordinary TCP connections. In contrast, an ordinary TCP connection sharing the network with a HS-TCP connection experiences much the same orderly congestion-control behavior as if there were several other ordinary TCP connections using the network.
Day is chief scientist for Riverbed Technology. He can be reached at mday@riverbed.com .