So, your company is growing, business is good, and in this time and age it means, most likely, that your company relay more and more on the network, as a means to an end, or as the end itself. Either way, this means that the network is an important thing. Quality, performance, stability, are all word that come to mind when we think of our expectation of “important thing”, and the network is no exception.
Realizing that the network is indeed important, your company decided to invest in a high quality WAN link, 1 Giga Bit speed, full bandwidth assurance at all times and 99.9999 uptime. Naturally you will expect that your services, which relay on the network, will be able to use up to 1Gig of bandwidth when needed, is it so?
Know, let us imagine a world, not exactly like our own, but a world in which quality and stability are a given, from the network perspective this means that the link is always up/active, that there is no packet loss and the provider reserves 1gb of bandwidth throughout his network. What would you expect from network performance in such a world? You would probably expect performance to be at its 100%, enabling your application to reach 1gb of throughput, but would it?
Since most application use TCP (it is a connection oriented protocol which implement mechanism that assure all data sent is indeed received, so it is reliable), let us examine an application using TCP.
There are few factors which effect TCP throughput:
- TCP window size.
- Delay (round trip latency).
- Packet loss.
TCP window size – is simply the amount of data one can send before waiting for an acknowledgment from the receiver.
Delay – is the amount of time for a packet to travel from source to destination and back.
Packet loss – is the amount of data that is lost, in percent.
In our example quality and stability are a given, so there is no packet loss (in the real world this is not always the case), so to calculate our throughput we will use just the TCP window size and delay.
We have the following network:
We will use the maximum possible TCP window size 64KB, and the delay is 17ms.
The formula for calculating TCP throughput is:
“TCP window size” in bits / Delay in second = bits per second
We will convert the TCP window size to bits:
64KB = 65536 Bytes, know convert to bits, 65536 * 8 = 524288 bits.
We will convert the delay to seconds:
17 / 1000 = 0.017 seconds.
Now let’s see what throughput can we expect:
524288 bits / 0.017 seconds = 30840470 bits per second throughput = 30.8 Mbps maximum possible throughput
So, on a 1gb WAN link, with a delay of 17ms, your application will reach only 30.8mb!
Things get worse, much worse, if you have packet loss. The following table will illustrate the packet loss effect on throughput:
| Delay | TCP throughput – no packet loss | TCP throughput – 2% packet loss |
| 0ms | 93.5 Mbps | 3.72 Mbps |
| 30ms | 17.4 Mbps | 1.73 Mbps |
| 60ms | 8.7 Mbps | 1.33 Mbps |
This TCP limitation and issues are well known and there are many solution to the problem of TCP throughput. RFC 1323 help mitigate some of the problems, but not all of them. And there are many more options.
Internet Binat can help you maximize your infrastructure, by implementing the suitable solution. We have the knowledge, the skills, and the services.
The conclusion is not that one should not invest in high bandwidth and high quality WAN links, the conclusion is one should know how to utilize the WAN infrastructure correctly. And we at Internet Binat know how.