Evaluation of Swift Start TCP in Long-Delay Environment

Summary This report presents the test results of the Swift Start algorithm in single-flow and multiple-flow testbeds under the effects of high propagation delays, various bottlenecks, and small queue sizes. Although this algorithm estimates capacity and implements packet pacing, the findings were that in a heavily congested link, the Swift Start algorithm will not be applicable. The reason is that the bottleneck estimation is falsely influenced by timeouts induced by retransmissions and the expiration of delayed acknowledgment (ACK) timers, thus causing the modified Swift Start code to fall back to regular transmission control protocol (TCP). Introduction The slow start algorithm (ref. 1) is used at the beginning of a transmission control protocol (TCP) connection to probe a network capacity and to establish a self-clocking process. Slow start probes the network by transmitting packets at 1.5 to 2.0 times the rate of acknowledged data in each round trip until the congestion window has reached the slow start threshold or a dropped packet has occurred. With this growth pattern in a high-bandwidth-delay product (BDP) environment, TCP may take several seconds to transmit at the maximum rate allowed in the network. For small transfers, as in command strings or small files, TCP may have completed sending all the data before reaching the full capacity of the network. Also, the number of packets being released into the network exponentially increases in large bursts during the slow start phase, causing the buildup of a queue in bottleneck routers. In a network with a high BDP, these router queues may be smaller than the maximum TCP window, which leads to the dropping of packets and poor overall performance. With a goal of solving these startup problems, BBN Technologies designed an algorithm called Swift Start (ref. 2), which is a combination of packet-pair and packet-pacing techniques. Packet pair is based on the spacing between two initial acknowledgments (ACKs) from data that have been sent in immediate succession. The algorithm provides an estimation of the current network bandwidth, thus allowing a TCP connection to obtain the network capacity much faster than slow start. Packet pacing is a technique that uses an estimated round-trip time (RTT) to spread out packets across an RTT, avoiding bursts of packets that are released to the network, and to establish an initial self-clocking process. Since limited testing had been done by BBN Technologies, the goal of the project reported herein was to fully evaluate the Swift Start code in a testbed environment using variables of file size, bottleneck link, delay, and fraction of capacity estimation in a single-flow transfer. The code was examined under the influence of different rates of user-datagram-protocol (UDP) background traffic inserted in the link. In the initial testing, we found and corrected some coding flow problems with the capacity estimation and pacing section in the BBN code. By testing the modified code, the results showed that capacity estimation helps to improve the throughput in small and moderate file transfers of the single-flow testing, but the code needs further changes to perform better in long file transfers and in a multiple-flow environment. The pacing-only tests showed dropped packets later in the connection as compared with regular TCP, which proved that the bursts of packets sent in TCP caused the network routers to be overloaded sooner