Slow File Transfer? My Network is Fine – It Has To Be My FTP Server
by Team AppNeta on

Raise your hand if an end user has complained of a slow file transfer?

You can’t tell, but my hand is the highest.

File Transfer Protocol (FTP) transfers have been around since the dawn of the civilization.  Not really, but it has been around for the duration of the internet. Point being, the FTP is everywhere. This made me think, how liberal is FTP when the network is not adequate?

We’ve used this analogy many times, but imagine FTP is a brand new 2012 V8 Ford Mustang.  On a clean highway, this car will go zero to 60 pretty quickly.  However, if you’re on a road with numerous potholes, perhaps I-95 outside of Boston, then that brand new Mustang can’t go faster than 30mph.  Applications and networks are the same way.  If the network is performing poorly, so will the application that is trying to communicate over it.

With the above being stated, I wondered what effect network health would have on the file transfer protocols.

To explore this, I set up a test scenario.  AppNeta support maintains an FTP server to do large transfers of various Appliance images to our customer.  Why reinvent the wheel? I put a 70mb file on this server.  From there, I would transfer it to a Ubuntu guest VM running on Oracle VirtualBox on a Windows 7 Professional host.  The FTP client on the Ubuntu was ol’ reliable Filezilla 3.

The parameters I altered were latency and RTT for one batch of the test.  For the second batch of testing, I altered packet loss.  These parameters were induced by implementing network emulation on the Ubuntu host.  The metric I used to track the success of each transfer was total time for transfer in seconds.

Network Latency

My original hypothesis was that packet loss would cause more havoc on the transfer than simple latency. My reasoning being that there are fewer retransmits with latency. It’s still traveling, just a taking a tad longer to get there. However, packet loss requires retransmits (see TCP).This isn’t the first time, and unfortunately not the last time, I was completely wrong.

When latency was added to the transfer, the time to completion growth was nearly exponentially. On a clean network the transfer took 86 seconds. However, when only 30ms of added latency was induced, the completion number jumped to 106 seconds. On the contrary, for packet loss, when 4% was induced the time to completion was only 95 seconds.

There are two conclusions drawn here.

First, the application (FTP) was fine; the network was adding latency. Therefore, don’t be so quick to blame the vendor/application.

Second, latency is indeed the ultimate application killer.

Filed Under: Networking Technology, Performance Monitoring

Tags: latency , network speed , NPM , packets