Alternatives to TCP

In the last Video Networking column, I described some of the headaches involved with trying to upload a file to an e-mail Web server. Most likely, Transmission Control Protocol (more commonly known as TCP) was one of the major sources of the problem. TCP is far and away the most commonly used protocol for data file transfer on the public Internet, and is also widely used for data transport on private networks around the world. In this column, we’ll take a look at some of the new technologies that are available to supplement or replace TCP in order to better support transfers of large media files over IP networks.


Briefly stated, TCP performance suffers as round-trip time (RTT) increases and as packet loss rates increase. In addition, throwing additional bandwidth at the problem has little or no impact on the overall throughput. These limitations are due to the mechanisms that TCP uses to ensure that each packet arrives at its intended destination. Essentially, the TCP sender determines when to send new packets based on receipt of acknowledgements that are sent from the receiver for each group of packets. On a link where packet losses occur or with high RTT, the total speed of the TCP connection can be very low, even if a high bandwidth data link is available.

Many of the implementations of TCP that are deployed on file servers and clients use a technique called additive increase multiplicative decrease or AIMD. This technique is used to control the rate at which packets are sent. In essence, each time a group of packets is successfully delivered, the transmission rate is increased by a fixed step (additive increase). In contrast, each time a group of packets is not successfully delivered, the packet sending rate is decreased by a multiple, often by a factor of two (i.e., cut in half). For the small flows over low-speed data connections that were present when TCP was designed (i.e.. text e-mails over 1200 baud dial-up circuits) these behaviors were reasonable and prudent.

However, when trying to fill a 100 Mbps pipe with data, it can take a while for the data rate to get up to the maximum, particularly on a circuit with a long RTT. Moreover, as soon as the maximum rate is reached and some packets are lost due to a buffer overflow, the transmit rate drops by half, and then slow buildup begins once again. This process tends to make the overall data transmission rate very uneven, and lowers overall bandwidth utilization.

Another issue of current TCP implementations is the fact that the AIMD algorithm constantly pushes network loads into an overflow condition. This occurs because the only feedback that the sender gets from the receiver is about whether or not packets are lost along the way. If packets aren’t lost, then the assumption is that the sending rate can be increased; if packets are lost then the sending rate needs to be decreased. In this situation, senders are constantly ramping up data rates to the point when buffer overflow occurs.

These issues can have a big impact on the transport of large media files. Experiments have shown that the total throughput of a link has little or nothing to do with the total speed of the link, and everything to do with the performance of FTP. For example, information proved by Aspera shows a Los Angeles-to-New York cross-country link with 90 ms of RTT and a packet loss ratio of 1 percent operating at a maximum throughput of 1.4 Mbps, regardless of the actual bandwidth capacity of the link. If a user wanted to send a 1 GB file over this link, it would take 1 hour and 42 minutes.


Two different approaches can be used to address the issues with TCP: improve the performance of existing TCP implementations or replace TCP with another protocol. Companies are currently offering both types of solutions today. Aspera offers a replacement for TCP called “fasp” consisting of a set of software applications for transporting large media files. FastSoft offers a hardware-based accelerator called “Aria” that improves the throughput of TCP downloads from a central server to remote clients that use standard TCP software. Let’s take a closer look at both products.

(click thumbnail)Fig. 1: Aspera’s fasp product is a protocol stack that replaces the file transfer functions of TCP with specialized applicationsAspera’s fasp product is a protocol stack that replaces the file transfer functions of TCP with specialized applications, as shown in Fig. 1. These applications operate over UDP, the User Datagram Protocol. UDP may be familiar to readers who have looked at video streaming architectures such as IPTV or the COP3 protocol that was recently standardized in SMPTE 2022, which both use UDP packet transport to achieve high packet throughput. One of the big benefits of UDP is that it formats and sends datagrams (packets) in a continuous stream without the constant stream of acknowledgments found in TCP, thus placing the data transmission rate under the control of the sender.

This freedom comes with added responsibility—fasp must ensure that the data file is transported intact from source to destination, and that data rates are not so high that they neither overwhelm the transport networks nor unfairly consume excessive amounts of bandwidth. These issues are both addressed by the double-ended nature of fasp, where both the sending and receiving application are used to ensure proper operation. These applications are responsible for monitoring the packet stream, detecting and retransmitting any missing packets, and measuring the overall performance of the link for optimization purposes.

FastSoft’s Aria platform is a hardware device that sits between a TCP data source and the ultimate data destination, as shown in Fig. 2. By being placed close to the source, a very low delay, low loss path can be established from the server to the Aria device, allowing very fast packet transport to occur. The Aria device then relays those packets to destination devices, using a set of carefully designed algorithms intended to optimally fill every packet buffer along the data path. Also, the round-trip delay for every packet is measured and tracked, so that this information can be used as part of the calculations to determine the optimal bit-rate.

(click thumbnail)Fig. 2: FastSoft’s Aria platform is a hardware device that sits between a TCP data source and the ultimate data destinationOne key to understanding the FastSoft technology is to look at the behavior of the algorithm that is used in place of AIMD, described above. Rather than using slow rate increases and rapid rate decreases, the Aria adjusts the bit-rate intelligently—using larger adjustments when the rate is far away from the calculated desired rate and smaller adjustments when the rate is close to the target. This allows the system to adapt more quickly to network changes, and to avoid the repeated cycle of overflowing the data circuit.


Both technologies can offer significant data transmission rate improvements. The cross-country link mentioned above consisting of a 155 Mbps OC-3 circuit with a 90 ms RTT and a 1 percent packet loss rate saw its utilization rate go up to 154 Mbps using the Aspera technology, reducing the time needed for transferring a 1 GB file to 55 seconds. Similarly, the Aria platform accelerated a cross-country OC-3 link with 80 ms RTT and 0.01 percent packet loss to deliver a 2.5 GB file in 2 minutes 39 seconds.

Of course, no solution is perfect. Fasp requires applications using this technology to be modified to incorporate the new protocol stack, so it is not currently available on all platforms for all applications. In addition, fasp users need to ensure that all the firewalls along the intended paths are configured to allow UDP traffic, which can be considered a security risk by some organizations due to the possibility of spoofing a UDP connection. In contrast, Aria uses a hardware device that is installed at each data source; this could be impractical for companies that have a large number of distributed or mobile data sources.

For more information on the technologies described in this article, please visit and