fasp File Transfer Compared to FTP

The following graphs compare file transfer throughput and transfer time for fasp file transfer and FTP file transfer in typical network scenarios. All fasp and FTP benchmarks are for file transfer tests run within the Aspera labs. In each test, a 1-gigabyte file was transferred between commodity Pentium-4 computers running Debian Linux, using a standard Debian Linux implementation of FTP and Aspera Scp for fasp file transfer. A nistnet network emulator was used to simulate network round-trip latency and packet loss conditions typical on the Internet. Actual FTP throughputs will depend on the particular implementation of FTP used, the operating system, and the particular network loss pattern, but the results shown are typical.

fasp vs. FTP on Gigabit Metropolitan and Wide Area Networks

Conventional TCP file transfer technologies such as FTP dramatically reduce the data rate in response to any packet loss, and cannot maintain long-term throughputs at the capacity of high-speed links. For example, the maximum theoretical throughput for TCP-based file transfer under metropolitan area network conditions (0.1% packet loss and 10 ms RTT) is 50 megabits per second (Mbps), regardless of bandwidth. The effective FTP throughput is even less (22 Mbps). In contrast, fasp achieves 100% utilization of high-speed links with a single transfer stream.

In the particular test shown, the fasp throughput on a gigabit ethernet MAN (509 Mbps) presses the disk read/write speed limits of the endpoint computers. Perhaps more important, fasp maintains this throughput even as latency and packet loss increase (505 Mbps at 200 ms/2%). FTP throughput degrades to about 550 Kbps under the same conditions. While this 1000X speed advantage over traditional TCP transfers is only evident on the fastest long-haul networks, it illustrates the difference in the fasp approach.

fasp vs. FTP on Cross-continental Links

Aspera fasp sustains the highest possible end-to-end file transfer rates on cross-continental and intercontinental file transfers where latencies are high and packet loss is variable. An FTP file transfer from LA to New York (90 ms) will achieve 5-6 Mbps when loss is low (0.1%). As congestion on the link increases (1%), FTP dramatically reduces its rate to 1.4 Mbps. In contrast, fasp transfers data at link capacity. On a 155 Mbps link with 90 ms/1%, fasp transfers at 154 Mbps, 100 times faster than FTP. Using a more typical 45 Mbps link, the transfer is still 30 times faster than FTP.

fasp vs. FTP on Intercontinental Links

fasp's throughput advantage over FTP is more pronounced on an intercontinental transfer. At a packet loss rate of 2% and latency of 150ms, an FTP file transfer between continents runs at 700 kbps, and can drop to a crawl during periods of high congestion. fasp maintains stable throughput at link capacity in around-the-world file transfers. Using fasp file transport, a 1-gigabyte data transfer on a 10 Mbps link at 2% loss will run consistently at 9.9 Mbps, and finish in under 15 minutes, regardless of distance. On a 45 Mbps link, the transfer finishes in 3.3 minutes. An FTP transfer under the same conditions takes several hours, and may terminate prematurely.

fasp vs. FTP on TCP Tuned for High Bandwidth-High Delay Networks

The throughput of FTP on links that have both high bandwidth and high latency can be improved by "tuning" the operating system parameters used by the TCP networking stack on the file transfer endpoints. The tuning usually involves increasing memory buffer sizes such that TCP can use the large data windows necessary to fill a high bandwidth - high delay link. TCP uses the concept of "windows" to throttle the amount of data the sender injects into the network, depending on the receiver's available capacity and the other link traffic. A window is the amount of new, unacknowledged data that TCP allows to be in flight between sender and receiver. In order to keep a link filled to capacity, TCP must use a window size equal to the bandwidth times the round-trip latency of the link, sometimes referred to as the "Bandwidth Delay Product".

The Bandwidth Delay Product of a very high bandwidth local link or a high bandwidth WAN link can be very large and exceed the default TCP buffer sizes used by the operating system on the file transfer endpoints. For example, a local gigabit ethernet link with 10 ms latency has a Bandwidth Delay Product of 1.2 megabytes: 1,000,000,000 bits/s * 0.010 seconds = 1.2 megabytes. A 45 Mbps cross-country link with 90 ms latency has a Bandwidth Delay Product of 494 kilobytes. In contrast, the default TCP buffer size on most operating systems is much less, usually 64 kilobytes. By raising the default buffer size to the Bandwidth Delay Product, in theory TCP will fill the link to capacity, and an ideal FTP file transfer will run at link speed. However, in practice, packet loss on the link will cause TCP to reduce its instantaneous window size dramatically, and reduce throughput below link capacity. The result is that tuning TCP improves FTP throughputs on local links where loss is low but has almost no impact on FTP throughputs over wide area links having some packet loss.

The underlying problem is that standard TCP is overly conservative in the face of normal packet loss for high bandwidth or high delay links. When TCP experiences any packet loss, independent of the cause, TCP assumes that network congestion is pending and applies a congestion avoidance algorithm. TCP reduces the window size exponentially and then slowly reopens the window to increase rate. On high-bandwidth or high-delay links, where relatively more packets are traversing more network nodes, some loss due to random error is normal, yet TCP assumes congestion and throttles the rate down. The higher the Bandwidth Delay Product, the smaller the packet loss tolerated before TCP throughput falls well below link capacity.

The graph above compares FASP, FTP over standard TCP, and FTP over TCP tuned for the Bandwidth Delay Product with all optimizations enabled, such as selective acknowledgments. When packet loss is 0.1% (one packet loss per 1000), tuning TCP improves FTP throughput (21 to 38 Mbps), but FTP is still 70 times slower than FASP (238 Mbps). On WAN links where packet loss is higher, tuning TCP has almost no impact on FTP throughput. In a coast-to-coast transfer (90ms/1% loss), Tuned FTP and standard FTP both run at about 1.5 Mbps. In this case the loss dominates, sending TCP into congestion avoidance and dramatically reducing throughput.

fasp over high-delay Satellite links

The high latency and bit error rates of satellite links severely hamper FTP file transfers, making large data set distribution or file upload over satellite impractical. FASP file transfer rates are immune to the distance and loss characteristic of single and multiple satellite hops. For example, a single FASP file transfer can fill a full transponder bandwidth (e.g. 45 Mbps) and will gracefully tolerate even the most extreme packet loss (over 30%), while FTP runs at 100 kbps or less and may not complete.

fasp vs. FTP on 802.11 Wireless

802.11 Wi-Fi and fixed-rate wireless networks are proliferating. However the promise of uploading/downloading personal data, large email attachments, or images from a mobile endpoint is limited today by the poor performance of TCP-based file transfers over wireless links. File transfers using conventional FTP or HTTP over wireless achieve a fraction of the specified capacity and are prone to wide variations in throughput and early terminations, depending on the link quality. Early experiments show that FASP improves the throughput of file transfers over standard 802.11 a/b/g connections by a factor 1.5 -2 and is more robust to the changes in link quality due to roaming or other traffic. As shown in the graph below, FTP throughputs and transfer times vary by +/-20% while FASP runs faster and at a steady rate. The FASP throughput and reliability advantage over standard file transfer may become even more necessary as wideband wireless enters the mainstream.