ServePath Blog

From the ServePath Knowledge Base:

Some users may experience slow FTP performance despite having high-bandwidth connections at both ends. The following hypothetical example illustrates this common issue.

For example, an FTP stream to one of our servers located in Texas from a server located within our network in San Francisco would peak at around 6 to 7 Mbps. This happens even though both machines at either end are connected to the Internet using a 100 Mbps link.

We ran several tests using a freely available utility called iperf, and obtained interesting results. While a single TCP stream would peak at around 6 Mbps, a single UDP stream would consume almost the whole available bandwidth at more than 95 Mbps. However, even though a single TCP stream would peak at around 6 Mbps, we could send multiple TCP streams and use much of the available link capacity.

The question then is why does one TCP stream peak at only 6 Mbps? This actually has to do with how flow-control is handled in a particular TCP implementation. Flow-control in TCP is dependent on window-size and the round-trip time (RTT) or latency, and both attributes can significantly affect TCP performance. For example, with the same link capacity and window size of (35,040 Bytes), if the RTT is 1ms, a TCP stream can use 280 Mbps of bandwidth. Increase the RTT to 50ms, and the TCP performance drops to 5.6 Mbps. Also, even the slightest packet loss can severely affect TCP performance. Our RTT from SF to the server in TX is around 45ms. That would explain the slow FTP performance.

Despite having plenty of bandwidth, we cannot circumvent the latency issue. It will take a certain amount of time for a packet to travel from one geographic location to another. Transmission is ultimately limited by the speed of light, which is not an insignificant factor. Furthermore, the paths over the Internet are not necessarily streamlined according to geography.

So then how can we achieve throughput of greater than 6 Mbps for a TCP stream? There are several solutions:

- Tuning TCP window size
- Using software that splits a single flow into multiple flows
- Leveraging Caching and Content Delivery Networks

There are several freely available papers on the topic of TCP performance over the Internet. This particular one explains it very clearly. Another useful link with vendor solutions.

Latest version of the KB article is here.

Below is a preview:

Title:	KB: Why is My FTP Transfer Speed Slower Than Expected
Description:	Some users may experience slow FTP performance despite having high-bandwidth connections at both ends.