Bandwidth Delay Product

Hello Paul

This is a very good question. The initial optimal window size is calculated based on the bandwidth delay product as described in the lesson.

However, because network conditions are not static and continually change, the window size must also dynamically change to accommodate these changes. Even if the optimal window size is calculated and used, the receiver may still be overwhelmed by the amount of data that is being received during the TCP session due to additional information being sent to it on other TCP sessions for example. Or because traffic has suddenly increased on the network segment due to file transfers that have been initiated in the meantime. The result is that it may be losing information and asking repeatedly for segments to be resent. If this occurs, the receiver requests that the window size be made smaller. After several successful segment transfers the receiver may request an increase in window size to increase efficiency. This may be done and if successful, the window size is kept…

These changes can occur multiple times over the lifetime of a session, and this is why the window size must be something dynamic in order to optimise the efficiency of the transfer.

I hope this has been helpful!

Laz

Hi Rene

On the bandwidth delay product your conversion from ms to second is not correct.
You converted 1ms to 0.01 seconds, this is not correct.
1ms =0.001seconds

Raul

1 Like

Hello Raul

Yes you are correct, thanks for picking that up. I will let @ReneMolenaar know. Here’s the specific part that is incorrect:
image

The 1 ms should be 10 ms or the value in the equations should be 0.001

Thanks again!

Laz

Thanks guys, it has been fixed.

Hi Rane ,does iperf command supported by Cisco switches like 3650 etc.

HI Rene,
We are making some test of bandwidth with IPERF.
I have two links of dark fiber connected to a Cisco OADM 8A. It is supposed that I have 20Gbps I made some test with IPERF with different windows size but it just gaves me like 0.44 Gbits/sec.

Does IPERF is telling me that I dont have the bandwidth I supossed to have?

iperf.pdf (161.9 KB)

Hello Vinod

iperf is a utility that runs on Linux, Unix and Windows operating systems. It is not a command that is actually implemented on a Cisco device itself. In the lesson, the iperf command was implemented on the Client and Server devices, which were PCs.

I hope this has been helpful!

Laz

Hello Helen

Because you’re using a high speed link, I suggest you try various values for the window starting with 128000, and keep doubling until you get a maximum throughput. A window size of 128000 is typical to maximise throughput on a gigabit link, so it’s a good start. Specifically, test out the following window sizes:

128000
256000
512000
1024000
2048000
4096000
8192000
etc…

For each window size, record the throughput. When you reach a maximum value of throughput, that is the maximum throughput that you can expect from the link.

If it is different than what you expect, you should then begin troubleshooting other issues. Let us know what results you get.

I hope this has been helpful!

Laz

Hi Lazaros, thank you for your reply.
I made a bandwith test with differents windows sizes and I get just 3.5Gbps but when I add the -P (number of parralel clients) with different windows size I get 8.6Mbps of bandwidth.

Now Im more confuse I dont know how many bandwidth does my link really has.iperf-windowssize.pdf (637.5 KB)

Hello Helen

Can you set up a different test without iperf? Try setting up an FTP client and an FTP server, one on each end of the link. Place a large file (several gigabytes if possible) and try to transfer it from server to client and see what kinds of speeds you get. This is a real world example, so it might more accurately state your link’s speeds. If speed is still limited you may find that there is an issue with your cabling or your terminations. Check out the error rates on the interfaces on both ends to see if that may be the culprit.

You can find large files to use for your tests by searching Google and typing “large test files to download”. Several sites have 1 and 10 GB test files that you can use. You will need to first download such a file to your server and then test the FTP transfer from server to client.

Let us know your results!

I hope this has been helpful!

Laz

I was thinking the same until saw Rene’s Post

2 Likes

Hi Rene,

how do we manually change the TCP window size on Windows 10 PC? and how? is there a command we can enter in command line?

Kind regards,

John

Hello John

Each program that runs on a Windows 10 computer creates TCP sessions has its own mechanisms to create and change its window size. However, you can adjust these parameters using the Set-NetTCPSetting command on the Power Shell. You can find out more information about this at the following link:

I hope this has been helpful!

Laz

Hi Rene,

I’ve got a question about maximum bandwidth speed.

The company I work for have a Layer 2 Ethernet circuit connecting our HQ to our DR site. This is a 1Gbps link and that’s also our Committed Information Rate (CIR). However, today my colleague was testing if we actually get 1Gbps speed between our HQ and DR site. He transferred a 1GB file from a PC in HQ site to a PC in DR site. When we saw the bandwidth speed on SolarWinds for the link it was only using 49Mbps when its actually a 1Gbps link. Note this is a small company that consists of only 30 employees and the link is not utilised much.

A point to also mention is that we have GRE Tunnel with IPSec encryption running over this link, so we adjusted the ip mtu to 1400 and tcp mss value to 1360 under the tunnel interface. Can these values limit the maximum bandwidth we can achieve?

Also, we are using 1Gbps everywhere on the network; PC NICS, Switches, routers, Cat5e cables, etc.

I’ve read online about this and some have mentioned this can be caused by the hard drive speed on the receiving computer.

Would really appreciate if you can shed some light on issues like this, I’ve seen this many times where you are not achieving anywhere near the maximum bandwidth whether on the LAN or WAN but I don’t know exactly where to start.

Is there anyway of testing the maximum bandwidth on the link via IP SLA? I know you can test the RTT value with IP SLA Responder configuration.

Many Thanks

Akhas

Hello Akhas

This is an excellent question, and it really highlights all of the parameters that are involved in an end to end communication that can affect the throughput of data.

Things that can affect this particular communication include:

  1. The application being used to transfer the files. Remember that when sending data using the SMB or FTP protocols, TCP is being used. This means that the receiver can regulate the flow of data using TCP flow control mechanisms. If the receiver can’t handle the speed (due to application, bandwidth, or hardware limitations) it will request that the sender slow down sending, which will ultimately reduce the throughput. This is also highly dependant on the operating system being used and how it manages the various TCP sessions.
  2. QoS policing and shaping parameters that are configured at various parts of your and the ISP’s network.
  3. Other traffic that may be on the network at the time.
  4. Overhead from tunnelling protocols.
  5. Method of measurement used by solar winds (are you sure it’s 49 Mbps and not 49 MBps?)

Now I know that you have taken many of these into consideration, as you mention in your post, but I am mentioning them here for completeness.

In order to remove such factors from the equation, my suggestion would be to use an IP SLA traffic generator as you mention in your post. More info can be found here:


Configure the generator on a device as close as possible to the ISP edge (possibly your edge router) and the responder also as close as possible to the network edge of your DR site. This way you eliminate the passage of traffic on your internal network which may also affect the result.

Next make sure to use UDP for the transmission so that you don’t involve any flow control that may limit the transmission.

Finally, use several measuring techniques, including both your solar winds monitoring system as well as using a policy map on the network devices using an access list as described in the above linked lesson. That way you can verify (or not) the measurements being taken by the monitoring system.

I hope this has been helpful!

Laz

Hi Laz,

Thanks for the answer, very clear explanation.

Yes I double checked the speed, it was only 49Mbps. I’ve been busy with other projects and hence was unable to implement and test what you’ve suggested. However, I will try scheduling a maintenance window next week sometime to so this.

1 Like

Hello Akhas

That sounds great. I’d be interested to find out your results and see what you get! Looking forward to it!

Laz

Hi Rene,

I am getting a little bit confused here.
As you stated in the last lesson “TCP window size scaling” that window size is the size of receive buffer. And it tells the sender how much data it can transmit before the receiver will send ACK.
So according to this the amount of data that can be transferred depends on the window size of receiver. But in this lesson you stated “data is transferred from the server to the client so you can ignore the default TCP window size for the client”.
Shouldn’t we take the window size of client into consideration? Could you please clear my doubt.

Warm Regards,
Tanya

Hello Tanya

When talking about “windows” in TCP it’s important to specify that there are several definitions. First, we have the window which is described in the TCP Window Size Scaling lesson. This is called the receive window and it’s purpose is to prevent the receiver from being overwhelmed with data, resulting in lost data. It is maintained by the receiver, and its value is sent to the sender within the acknowledgements. The sender will adjust the window size, which is the maximum number of bytes it can send before receiving an ACK.

But there is another window involved in the TCP process, and this is the congestion window. This is actually maintained by the sender. This window is a way of preventing a link from being overloaded with too much traffic, and it is determined by estimating how much congestion there is on the link.

A sender will use both the congestion window, and the receive window to determine how much data it can send at any one time.

For the specific example in the lesson, you can see that the TCP window size on the client (the receive window) is 85.0 KByte, while the TCP window size on the server (congestion window) is 15.6 KByte. Since the congestion window size is smaller than the receive window size, the receive window size can be ignored. Or in other words, it will not play a role in limiting traffic in this particular case.

As the congestion window size is increased, the throughput increases as well. When this happens, the receive window size still says 85.0 KByte (default) but this may be renegotiated during transfer, and the traffic is able to increase further.

Keep in mind that CCNA and even CCNP certification exams do not touch much upon the details about TCP windows, and this is why the distinction is not made between the congestion and receive windows. Only the receive window is actually covered in detail in the topics of the exams.

I hope this has been helpful!

Laz

1 Like

Thank you Laz. It was really helpful.

1 Like