What is a TCP Window

What is a TCP Window

I first became interested in learning more about TCP while studying for the CCNA. Although the author’s description was desperately vague and for the most part in-accurate, it did spark an interest in further understanding this topic. That is when I discovered that a description that made sense was difficult to come across. Simply Googling “TCP Window” was all but useless and resulted in even more confusion. Nearly all videos on Youtube have an outdated or inaccurate description that often times confuses other related technologies like window scaling or the sliding window. Even to this day there is no Wikipedia article on the topic of what is a TCP window. Now I’m not saying that the topic isn’t at all addressed online, but sifting through the many topics surrounding windows is a difficult chore. The simple description of what a window is, is rarely made clear. This sent me down a rabbit hole of trying to answer that simple question “What is a TCP Window”.

So the “Explain like I’m five” answer is: A TCP Window is a range of bytes (broken up into packets) that is burst out all at once before pausing and waiting for the acknowledgements of those bytes to be returned. When all of the acknowledgements are received, a new window is sent. The sending device bursts a chunk of data, then the receiving device bursts the acknowledgments the other direction. If a window is 64KB, that data is placed on the wire as quickly as resources allow. The bytes will be given sequence numbers and each byte will be placed on the wire in order. That is when the sending machine waits and listens. The moment the receiving device begins receiving the first bytes it begins the process of generating acknowledgments. These ACKs will be sent the reverse direction back at the sending device confirming to the sender that those bytes have been received. But, the sender still waits. When finally all 64KB are confirmed, it can now send a new window.

The size of the window determines the speed at which data can be sent. The bigger the window, the less time TCP has to wait to send the data. For example: if you intend on sending 10MB using a 500KB window,  TCP will have to stop and wait 20 times to transfer all the data. Now if only 100KB window is used, than TCP will have to wait 100 times for the same amount of data. Bigger window equals faster throughput. That of course is a hugely simplistic example, but I think you get the point.

I mentioned the stop and wait time between windows. That duration of time is known as RTT (Round Trip Time). That is the amount of time from the moment a byte leaves the sender to the moment the ACK for that byte is received back at the sender. Because TCP is waiting to confirm all bytes have been received, it makes the time between each window equal to the RTT of the last byte sent. This is also known as latency or delay. You can get a working knowledge of RTT by simply pinging something. The return value will be roughly the delay of the path and the duration of time between each window. However in Microsoft products, the ping command doesn’t display microseconds if you are on a low latency LAN.

Adding to the example above let’s say we are sending that 10MB over a network with a 50ms round trip time. Using the 100KB window it would take 100 times the RTT which is a full 5 seconds. Using the 500KB window size it would take 20 times the RTT which is only 1 second. As you can see the size of the window dramatically impacts performance because it removes RTTs

Controlling the size of the window is of great importance. For the most part, the windows are in constant change. Rarely is it that two windows back to back are exactly the same size. This constant up and down is TCP controlling the flow rate to adapt to the conditions of the network and both the sending and receiving machines. If the window is too large for the network or the receiver to handle there will be packets dropped. If a window is too small, than it is not fully utilizing capacity.

TCP will most always attempt to send as quickly as resources allow. The modern TCP uses both simple and very complex methods in determining the appropriate size of the window. Most of the work in determining this value is done by sending the device using something known as congestion control. Different operating systems will use slightly different methods of congestion control but the point of it is really the same, adapting to network conditions.

There are three primary factors in determining the window size: Sender capacity, network capacity, and receiver capacity. The TCP sender will often but not always, use packet loss as a measuring stick, a gauge to determine the speed limit of the intended path. If loss occurs at a 2MB window, than that’s too fast, time to reduce the window size. If the path includes the internet or possibly a WAN, than typically the loss is due network resources in some form or another. However, on high speed switched LANs the receiving device will likely cause the losses due to it getting overwhelmed. Packet loss is normal and even purposely triggered in order for the sender to set that speed limit. The initial mechanism that TCP uses to set the speed limit is known as slow start. After slow start is run, the sending TCP now has a ceiling for its send rate. That is when the congestion control algorithm kicks in and begins throttling the window size up and down based on loss or in some cases RTT.

In conclusion, TCP windowing is a deep and complex topic and I do not want to get too far in the weeds into the nuances.

https://www.youtube.com/watch?v=1Gqj-dXgVrI