Does it helps adding more bandwidth ,to long distance WAN while trying to achieve better performance ?

Posted in:

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:

  1. TCP window size.
  2. Delay (round trip latency).
  3. 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:

DelayTCP throughput – no packet lossTCP throughput – 2% packet loss
0ms93.5 Mbps3.72 Mbps
30ms17.4 Mbps1.73 Mbps
60ms8.7 Mbps1.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.

Protect your corporate secrets
Sign up now for a FREE corporate security checkup




    Do you like an Article? Share with professionals!

    LEARN MORE ABOUT HOW WE
    CAN HELP YOUR BUSINESS
    FILL UP THESE GAPS

    Please fill in your info:





      Recomendations:

      Internet Binat is an excellent company with great products and outstanding support.The Network and Security Solutions supported by them are resilient, user friendly, secured with a low and affordable cost.Their support team always gives us high priority and attention
      Erez Greenbaum
      Erez Greenbaum
      08:11 10 Sep 19
      I am working side by side with Binat an several years, and was constantly amazed with their business insight and brilliant ways to solving problems.We was setup more the 15 MPLS line for our business around the world, which gave the company a significant advantage on top of the competitors.I really hope that our paths will not diverge in the future, and would recommend with all my heart working with Binat Internet and take advantage of their incredible and rare qualities.
      Alex Levin
      Alex Levin
      14:27 19 Aug 19
      Internet Binat is at the top of WAN services.Adama is working very closely with them for the last couple of years in some very challenging parts of the globe.Without the solutions they provide our job and normal user's productivity around the world would not have been possible.They are professional, committed and above all give superb service !Internet Binat can take you from planning board to execution with flying colors. Strongly recommend?
      Roni Barzelai
      Roni Barzelai
      13:46 19 Aug 19
      We get the absolute pleasure of working with Binat Internet for the last 5 years.We are worked on challenging and innovative projects on a global scale.I believe that every organization that would work or interact with Binat Internet will benefit dramatically from that. I want to note the excellent technical round-the-clock support, especially the Israeli team. Team is ready to deal with difficult situations and solve the problems on time.Any of your problems will be solved ASAP.Will be happy to recommend Binat Internet every time, knowing the benefits and attitude they are bringing with them to every project.
      Valery Kucher
      Valery Kucher
      11:32 18 Aug 19
      The excellent company,High professional levelYou always can trust the technical people that help you in any situation.
      Igor Vinokur
      Igor Vinokur
      14:27 14 Aug 19