When it comes transferring large files or data sets ( say bigger than 10 Gigabytes), many people forget that the transfer time becomes significant.

Transferring of a 20 GB file

Let’s say that you are transferring a 20 Gigabyte file over an Internet or intersite connection with bandwidth that is less than Gigabit. (If you are measuring interactive traffic flows you need another technique).

20 000 Megabytes * 8 bits per byte * 1 000 000 bits per Megabyte= 160 000 000 000 bits

When we pack this raw data into a TCP/IP packet (e,.g L3 packet headers and L2 framing) the data set will expand by about 40% (that is my rule of thumb).

160 000 000 000 bits plus 40% encoding overhead = 224 000 000 000 bits of network data.

If you can transfer this data (without encryption) at, say, 10 megabits per second:

224 000 000 000 bits / 10 000 000 bits per second = 22400 seconds = 373 minutes.

So we can expect the transfer at 10 Mbps to take around six hours (give or take a bit). Transferring the file at 100Mbps will take about 35 minutes.

Impact of Latency

This calculation is a best case and assumes that:

• there is no packet loss, and thus no retransmissions
• that there is no significant latency in the transmission path

Application Latency is the time taken for a data to pass from the application, propagate from A to B, and then be acknowledged from B to A, and be handed to Application to release the API data buffer.

Latency Rules of Thumb

My rule of thumb for circuits between 1 to 10 Megabits per second is to reduce the throughput by another 10 to 15% for intra-continental traffic, and 20 to 25% for Major economies in the northern hemisphere( UK, Europe, US), add more for the old Eastern Bloc and emerging countries (such as Turkey). Think hard and make your own choices for longer distances such as Australia, Japan, China etc.

Encryption Inflation

Remember that adding encryption (IPSec or SSL) will further inflate the amount of transferred data. The actual impact will depend a lot on average packet size. IPSec typically add 40 bytes to the header, which has less impact for a large data transfer with an MTU of 1350 bytes that for an interactive session exchanging packets with an MTU of of 400 bytes.

Often forgotten is the encryption and decryption delay that makes teh transfer more latent.

Rule of Thumb: add another 10 to 15% if you choose to encrypt the transfer.

Worst Case

So coming back to our original plan.

224 000 000 000 bits / 10 000 000 bits per second = 22400 seconds = 373 minutes.

Add 20% for the UK to US data transfer.

Add 10% for Encrypting into IPsec tunnel.

373 minutes * 20% * 10% = 492 minutes.

Now our chart looks more like this:

Wrapping it up

These rules of thumb are important because these are what you use in a design meeting before the idea turns into a project. You can save days of work by knowing rough numbers in advance. When the pony-tailed Unix Admin at the meeting casually throws out “and transfer the 20GB tile images using the VPN to China” you can do some quick numbers and instantly ask for another £250K for WAN upgrades (which of course will put that bright idea into the bin).

Near enough is usually good enough – Etherealmind.

Postscript

Not that these calculations are for file transfers which is easier to define. Trying calculate 20 GB of interactive traffic is much more difficult because the underlying condition is indeterminate. Beware.

The best possible network performance is achieved when the network pipe between the sender and the receiver is kept full of data, that is, the ‘in-flight bytes’ is set to the maximum that a sender and receiver can buffer before an acknowledgement is issued. This ‘should’ occur when transferring a large file and thus issues such as BDP and TCP Windowing are not really relevant.