TCP Performance Tips (Huston)

This is based directly from research by Deoff Huston, Australian National University.

The ever so popular TCP provides an reliable end-to-end transport service. TCP is adaptable; as it adjusts its behavior according on the networks state, TCP is not predictable. There are two generalized classes of TCP’s usage; interactive applications that have short-delay / small data transfers, and applications with reliable volume data transfers that have large packet data streams.

TCP’s flow-control mechanisms’ objective is to adjust TCP flows in a network so that they cooperate fairly; each getting a fair share of the networks resources. This is achieved by the manipulation of the congestion window; the maximum amount of data TCP senders can have in transit is the minimum of the send-window size and congestion window size. There is three major parts to TCP’s flow control; a flow control mode called Slow-Start, another flow control mode called Congestion Avoidance; and the underlying logic that moves between the two modes. These modes are littered with problems that essentially cripple TCPs performance.

A sender very first begins in TCP Slow Start mode. Slow Start mode always begins by setting the initial send-rate (of the congestion window) to permit only one segment in transit. As time progresses, for every acknowledge the sender receives, Slow Start increases the send-rate to permit an additional segment to be in flight. This gives an exponential increase of the send-rate, as generally the congestion window doubles every RTT. Eventually this exponential increasing of the send-rate stops and enters Congestion Avoidance mode; Slow Starts objective is to probe the network to discover approximated parameters about the networks resources. This transition of modes can be triggered by either of the following three events; the congestion window exceeds the size of the receivers advertised window, or when rate exceeds the slow-start threshold rate (this value is determined by previous congestion experiences), or when TCP infers that congestion in the network occurs. TCP infers network congestion from packet-loss which can occur in two ways; either when a sent packet has been left un-acknowledged for to long (where the retransmission timeout value constitutes the period of what “to long” is), or when a duplicate acknowledgment has been received. It is important to note that duplicate acknowledgments are not a reliable source for inferring congestion (for example, they are transmitted when a receiver receives packets that are out of order). TCP’s patch for incorrect congestion inferences via duplicate acknowledgments is its fast-recovery mechanism (this mechanisms focus is to quickly recover from small packet losses – small packet losses usually don’t indicate heavy network congestion).

When Congestion Avoidance mode is activated, the send-rate increases in a linear fashion: increasing the rate at one segment per RTT. Slow Start mode must be re-entered if packet loss occurs due to timeouts because of the lack of information gathered about the network state. This effect can be very inefficient when timeouts are due to transient network problems. Transitioning back to Slow Start however can be canceled whenever three duplicate acknowledgments are received as they still indicate that the network is at a healthy enough state to continue in Congestion Avoidance mode.

TCP’s performance can be improved by using Random Early Detection (RED). RED permits a router discard a packet even when there is free space its queue. The packets are discarded in such a way that there is a higher probability of discarding packets from TCP sessions with larger window sizes (as opposed to smaller winder sizes). RED essentially creates small-scale congestion-events with the intention of sending TCP sessions messages asking them to back-off, these small-scale congestion events are created strategically to avoid long-periods of large-scale congestion events from occurring. RED avoids situations where all TCP flows back-off at the same time die to experiencing congestion. This ensures that connected hosts are always making use of the networks resources. The probability of discarding a packet is weighted to target TCP sessions that consume most of the networks resources. Although TCP sessions experience packet lost they generally can avoid entering Slow Start mode since packets are randomly dropped. When packets are randomly dropped, a subset of the queued packets are still permitted to pass through the routers, which in effect the sender will eventually receive duplicate acknowledgments; canceling a transition in entering Slow Start mode.

A further advancement of RED is to replace is packet-dropping scheme to instead mark TCP packet that would have been dropped (due to RED) by setting the CE (Congestion Experienced) flag bit. This alternative scheme is called Explicit Congestion Notification (ECN). ECN has moderate performance increase over RED’s packet-dropping scheme with large bulk data transfers. ECN has a more notable improvements RED’s packet-dropping scheme with short TCP transactions; experiments have shown that RED with packing dropping may cause a six-second retransmit delay, whereas ECN can avoid such delays as it does not attempt to drop the very-few packets involved in such small transactions. However ECN is not yet supported (at least in the context of Ipv4) as there has been no explicit standardization for ECN flags within the IP headers, it may be some years for it to be widely deployed. RED however has a more rapid introduction to the Internet; due to it not having to change anything in the IP / TCP protocol stacks (it only has to change the behavior of the routers queue-management).

Optimizing TCP’s performance to suit a specific network has been a wide area of research. Some key recommendations for tuning TCP include:

  • Use a good TCP protocol stack.

    The finger shouldn’t be pointed at the network infrastructure when poor throughput for TCP sessions are experienced; often the performance can be better optimized through adjusting the protocol stack.

  • Implement a TCP SACK mechanism.

    This helps cut down on the retransmissions of payload packets.

  • Implement large buffers with TCP window-scaling options.

    This can assist the sender in adapting to a wider diversity of network paths by permitting a larger volume of in-transit traffic.

  • Support TCP ECN negotiation.

    This will enable the use of ECN: generally improving on RED’s performance.

  • Use a higher initial TCP slow-start rate.

    TCP currently begins the slow-start rate at 1 MSS per RTT. This is geared to accommodate for low-speed links with limited buffers. However, for networks that can easily handle faster rates, the Slow Start transfer rates can climb faster by starting its probe-packets with more than just a single packet.

  • Use robust host platforms to drive the network.

    Avoid servers becoming the bottleneck of their networks; try to use high-performance machines to make full use of network resources made available to the servers.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s