Auto Tuning Enabled FTP Client And Server, v2.0 FAQ

What is "Automatic TCP Window Tuning"?

The TCP window size is by far the most important parameter to adjust for achieving maximum bandwidth across high-performance networks. Properly setting the TCP window size can often more than double the achieved bandwidth.

With TCP, each segment header contains a field called "advertised window" specifying how many additional bytes of data the receiver is prepared to accept. We think of "advertised window" as specifying the receiver's current available buffer size. An important fact about TCP is that the sender is not allowed to send more bytes than the advertised window. This is TCP's flow control mechanism. To maximize the performance, the sender should set it's send buffer size and the receiver should set its receive buffer size to no less than the capacity of the TCP pipe. Usually this number is the product of bandwidth and round-trip-time (bandwidth-delay product).

The default values of socket buffer size differ widely between implementations. Older Berkeley-derived implementations would default the TCP send and receive buffers to 4KB, but newer systems use larger values (up to 64KB). We try to set the TCP socket buffers to an optimal value by detecting the bandwidth-delay product at connection setup time. Thus, even if the default socket buffer size is small, we can still achieve a high data transfer rate. For those connections with a low bandwidth-delay product, the socket buffer size will remain small in order to conserve memory usage.

The approach:

We implemented a basic Automatic Buffer Tuning scheme using Internet Control Message Protocol (ICMP). With our specific goal that the code can be easily embedded in a TCP application, we specified the following requirements:

Automatic TCP buffer tuning happens at TCP connection setup time and remains the same within a single TCP session.
Out-of-order delivery in the network should be tolerated.
The network can be unstable.
Additional network traffic incurred should remain low.
Additional time required for automatic buffer tuning should be kept to minimum.

Since we set TCP buffer size to the same as the available bandwidth-delay product, the problem is essentially to acquire available bandwidth and RTT with minimum cost of time and traffic and at least a coarse-grained accuracy. We follow the following steps to achieve this:

Send out a series of fixed-length ICMP_ECHO packets as fast as possible. Time-stamp each packet and associate a unique sequence number with each packet.
Measure the RTT by comparing the arrival time of the echoed packets with the time-stamps contained in the packets.
Record those packets that arrive in-order (consecutive sequence numbers) and the inter-arrival times. The packet length divided by the inter-arrival time is the assumed available bandwidth.
Determine the bandwidth-delay product by multiplying the bandwidth numbers by their corresponding RTTs, then multiply the median of the products by a constant factor (1.0 in our implementation) and return it as the result of our measurements.

We estimated the accuracy of this implementation using Iperf 1.1.1 TCP tuning (manually). The result shows that in almost all cases the TCP buffer sizes from above calculations fall within 20 percent of the optimal TCP socket buffer sizes achieved by manual tuning with Iperf.

Why should I use Autotuning enabled FTP?

If you ftp large files and those transfers take longer than you would like them to, then you should use Autotuning enabled FTP to speed up your file transfers.

How does Autobuf perform compared to normal ftp?

Autobuf achieves a greater file transfer speed (Ie., higher throughput/goodput), and conserves system memory (RAM) on end systems without any associated performance tradeoffs. Autobuf also allows an end system to support a larger number of socket connections and generally has more network-friendly behavior.

How does Autobuf speed up file transfers?

Normal FTP clients and servers use the default socket buffer sizes provided by the host operating system. For example, if the default socket buffer size were 64KB, then every file transfer would use a TCP socket connection with a fixed sending/receiving window size of 64KB. If the file transfer is over a high speed network with a Bandwidth Delay Product 4MB, for example, then the 64K buffer would be the bottleneck, since it would prevent optimal utilization of network capacity. By testing the connection beforehand and measuring the 4MB pipe capacity, Autobuf is able to set the sending/receiving windows for the socket connection to the more efficient value of 4MB on both sides, and therefore achieve a high speed transfer.

IMPORTANT NOTE: Simply setting your TCP window buffer size to a large value does NOT necessarily improve your transfer speeds. It may, in fact, cause things to become worse, depending on the exact characteristics of the specific network connection in question. More is not necessarily better in this context.

How does Autobuf work?

Autobuf calculates a one-way Bandwidth Delay Product (RTT * overall minimum bandwidth) at the beginning of a file transfer and then sets the TCP buffer size to the most efficient value for that particular tranfser. In other words, it determines the optimal TCP buffer size for the two ends of a given, specific file transfer connection in order to allow maximum throughput while simultaneously incurring minimum loss due to insufficient network capacity. In this way, by completely filling up the network 'pipe', it achieves the maximum throughput. At the same time it does not overload the network by sending more data per unit time than the network can handle.

How does Autobuf help conserve memory compared to normal ftp?

If your OS provides a default sending/receiving window size of 2MB and you attempt to transfer a file over a network path that has a Bandwidth Delay Product of 100KB, the 2MB of memory each end system would reserve by default for the transfer is very wasteful. By measuring the 100KB "pipe capacity" (Bandwidth Delay Product), Autobuf avoids wasting memory by making sure that the socket is only allocated 100KB of memory for its sending/receiving windows.

How does Autobuf allow a potentially larger number number of socket connections to exist on the end system compared to normal ftp?

By utilizing memory more efficiently (as detailed above), Autobuf "increases" the amount of system memory available to other socket connections. This has the advantage of increasing the number of potential socket connections that the OS can provide at any given point in time.

What method does Autobuf use to measure optimal buffer sizes?

Autobuf sends back-to-back ICMP packets and uses the packet interarrival times to calculate the Bandwidth Delay Product.

How good is Autobuf's averaging mechanism?

Autobuf discards the upper and lower quartile of readings and uses the average of the remaining data to determine optimal buffer sizes.

Would the Autotuned FTP client give any benefit if used in a connection to a normal (Ie., non-tuned) FTP server?

It may. This is because the server side buffers might still be a bottleneck to achieving high file transfer speeds. If the server side buffers are not adjusted to match the (large) buffer size calculated as optimal by the client, setting large buffer sizes at the client end will not help improve performance.

Does Autobuf make any assumptions regarding the symmetry of the network connection?

Yes. Autobuf sets both sending and receiving buffer sizes based on a one-way measurement. (Ie, Autobuf assumes symmetry.) However, tests in this area have shown this not to matter a great deal.

Contact DAST Blank Space Last reviewed: December 31, 1969
NLANR || Applications Support || Engineering Support || Measurement and Network Analysis