# TCP Window Size Scaling

Hi Rene,

What do you mean by

Window size value : 400
Calculated Window Size : 25600
and window size scaling factor : 64

Also the meaning ----

Relative Sequence number & Relative Ack number .

br//
zaman

Hi Zaman,

Originally the window size is a 16 bit value so the largest window size would be 65535. We couldn’t add more bits to the TCP header but it was possible to reassign the purpose of those 16 bits.

What we do nowadays is that we use a scaling factor so that we can use higher window sizes.

For example, the window size value is 400 and the scaling factor is 64.

400 x 64 = 25600

In my lesson one of the screenshots also showed a windows size of 132480.

Window size value = 2070
Window size scaling factor = 64

2070 x 64 = 132480

Here’s a short explanation of the relative sequence and ACK numbers:

Rene

hi thank you for your article

i have one qustion

wireshark show that length is 1460(mss)

how is the value selected between two host ?

isn’t it possible to exceed that value ?

thanks

Hi Mungi,

Most operating systems will look for the interface MTU and set the TCP MSS accordingly. For example, Ethernet has a MTU of 1500 bytes.

The IP and TCP header are 20 bytes each, so that’s 40 bytes in total. 1500 - 40 = 1460 bytes so that’s your TCP MSS.

The maximum size of an IP packet is 65535 bytes so theoretically, you could set the TCP MSS to 65535 - 40 = 65495 bytes. It’s unlikely to see this though, since you exceed the interface MTU you will have to fragment these way too big IP packets before you can send them.

Rene

Hi Rene,

I have tow question about Windows size :-
1 - Calculation of windows size depends on what ? or what are the windows size calculating algorithm ? is there any formula that used to calculate the windows size ? and this formula depends on what if it exists ?
2 - Can we modify the window size manually if we can how to do that ?

Best regards,
Hussein samir

Hello Hussein!

First lets take a look and see what is meant by the window size: The window size indicates the size of a device’s receive buffer for the particular connection. In other words, window size represents how much data a device can handle from its peer at one time before it is passed to the application layer. This buffer size can change based on the hardware being used (physical memory available on the NIC for buffering for example) as well as by the total number of TCP sessions the device is taking part in at any given time. Of course this window size may change dynamically. If there are too many errors, the window may become smaller. If there are no errors and other TCP sessions have ended and buffer space on the NIC is available, the window may get bigger. The actual value of the window size that is sent by a device to its peer is calculated by the OS of the device based on the above characteristics.

It is important to note here that window size is also affected by latency as well as bandwidth. Under “normal” or more common circumstances, these factors don’t enter into the equation. There are however cases where you would want to tweak the window size, and such an occasion is described below.

The maximum window size is configured based on the usual latency and bandwidth that we see in the vast majority of networks. However, on high speed high latency networks such as the connections between countries and continents, regular TCP window sizes won’t cut it. On these networks, small receive window sizes can limit throughput to a fraction of the available bandwidth.

If the window size is too small, a sender may transmit an entire TCP window’s worth of data very fast (high bandwidth), and then have to wait until the packets reach the distant remote site (high latency) so that acknowledgements can be returned, informing the sender of successful data delivery and available receive buffer space. In such a situation, there is a lot of time wasted without sending data. In these cases, window size must be increased beyond what would normally be the case in a LAN or WAN.

So it is possible to increase the window size, however, these changes would be done on the end devices that have created the TCP session and how that would be done depends in the systems used. TCP is layer 4 so routing and switching devices in between will not have any information concerning the TCP session details.

I hope this has been helpful!

Laz

Really excellent explanation on a very difficult topic. The wireshark captures really illustrate the points. This is the best way I have seen this topic described to get the idea across.

1 Like

Would someone please help me understand the relation among sequence number, acknowledgement and window size? I am totally confused when I am putting all three things together. Thank you so much.

Hello Azm

Yes, these numbers can be confusing. Here is an attempt to clarify these parameters:

The first thing to keep in mind is that in any TCP communication, there are actually TWO sequence numbers and TWO acknowledgement numbers: those of each party in the exchange of data. For the sake of this example, and for the diagram below, let’s call these SNL and SNR for Sequence Number Left and Sequence Number Right for the left and right hosts. Similarly, the acknowledgement numbers will be called ANL and ANR.

Note, these abbreviations are my own and are not generally accepted. I am using them only for the purpose of this example.

Take a look at this diagram:

The current state of this diagram is when the three way handshake has already been completed and transmission of data has begun. The current window size is 10.

So, the left host begins transmitting and sends a frame where SNL is 1 and ANL is 1. The SNL and ANL have been determined after the procedure of the three way handshake. (To find out how these are initially determined, take a look at Rene’s lesson here: https://networklessons.com/cisco/ccna-routing-switching/introduction-to-tcp-and-udp/ )

Since the window size is 10, the left host will send 10 bytes (this can be sent in one or more segments) and the header of the segment will have an SNL of 1 and an ANL of 1. Once 10 bytes are sent (the window size) the left host will stop.

The right host will continue to receive data and will do nothing until 10 bytes have been received. Once they have been received, it will compose an acknowledgement segment with the following information:

SNR = 1 This has been determined after the three way handshake. Note this is independent of the SNL
ANR = SNL + window size = 11 This essentially is the number of the next expected byte

Once this acknowledgement segment is received by the left host, it prepares the next batch of bytes to be sent, specifically, 10 since the window size is 10. In the segment it sends, it puts the following values:

SNL = ANR = 11
ANL = SNR + 1 = 2

And the process continues.

I hope this has been helpful!

Laz

1 Like

Hi Rene,

Can you please clarify the difference between Window Size Value and Calculated Window Size?

Also is the Scaling Factor value fixed i.e. 64?

Regards
Avinash

Hello Avinash

* Window size is the current size of the window in bytes.
* Scaling factor is a multiplier sent back along with the acknowledgement by the receiver that indicates to the sender that a new window size is requested.
* Calculated window size is the new window size that has been requested. This is determined like so: Window Size * Scaling factor = Calculated window size.

So, you would see on your wireshark output something like this:

``````window size value:593
{Calculated window size: 151808}
{Window size scaling factor: 256}
``````

You can confirm the above by doing the math: 593*256 = 151808

I hope this has been helpful!

Laz

Hello Laz,
Thanks for taking the time to explain it to me and I am feeling like I am almost there. I just need clarifications for a few more questions. I was always thinking that when one host is sending some data to another host, the sender will break that piece of data into smaller pieces(called segment in transport layer) and puts a tag(sequence number) on every single segment so the other end(receiver) can organize them in the right order by using the sequence numbers.
According to your explanation, it seems like what I knew was completely wrong because you are referring sequence number to window size(the amount of data is being sent). So what is the mechanism a receiver uses to track every single segment and organize them in the proper meaningful order?
One more thing is very confusing to me. In Rene’s tutorial, he is saying “H1 has setup a connection with H2 by using the 3 way handshake. We are sending 10 bytes of Data which means our “window size” is 10 bytes. The sequence number is 10”, but in your example even though when Left device is sending the first chunk of data of 10 bytes, still the sequence number is 1. I am not sure why. Would you please explain it to me? I thought the sequence number would be 10 since Left device is sending 10 bytes of data.
What field of a packet represents how much data that packet is carrying?

Thank you so much for your great help.

Best Regards,
Azm Uddin

Hello AZM

I can understand the confusion. Keep in mind that the window size, the sequence number and the number of segments sent are somewhat independent from each other. What do I mean?

Well, let’s say we have a window size of 21000 bytes. It is very unlikely that this will all be sent in one segment. It will definitely be split into several segments. The window size is “the number of bytes sent before an acknowledgement is required from the receiver.” These bytes can be sent in one or more segments. So, let’s take the following example:

Host A is sending a total of 100000 bytes (or 1 KB) of data to Host B. The window size is 7000 bytes. Let’s say the maximum segment size (which is affected by the Layer 2 and Layer 3 MTU configuration) is 1500 bytes. Host A will begin sending a series of segments with the following elements (SEQa is the sequence number sent by host A):

**Segment 1: SEQa = 1, Window Size = 7000, segment size = 1500 Bytes**
**Segment 2: SEQa = 1501, Window Size = 7000, , size = 1500 Bytes**
**Segment 3: SEQa = 3001, Window Size = 7000, , size = 1500 Bytes**
**Segment 4: SEQa = 4501, Window Size = 7000, , size = 1500 Bytes**
**Segment 5: SEQa = 6001, Window Size = 7000, , size = 1000 Bytes**

At this point, 7000 bytes have been sent. The TCP window has been exhausted. Host A stops sending and waits for a response. Assuming all went well, Host B send the following response:

**Acknowledgement from Host B to Host A: ACKb = 7001**

The ACKb number returned is the next expected byte, that is, byte 7001.

Once Host A successfully receives this acknowledgement, it continues with the next batch of segments:

**Segment 1: SEQa = 7001, Window Size = 7000, , segment size = 1500 Bytes**
**Segment 2: SEQa = 8501, Window Size = 7000, , size = 1500 Bytes**
**Segment 3: SEQa = 10001, Window Size = 7000, , size = 1500 Bytes**
**Segment 4: SEQa = 11501, Window Size = 7000, , size = 1500 Bytes**
**Segment 5: SEQa = 13001, Window Size = 7000, , size = 1000 Bytes**

Host B sends the following response

**Acknowledgement from Host B to Host A: ACKb = 14001**

… and so on…

So to specifically answer your question, yes sequence number is used to put the segments back in the proper order while window size is the number of bytes that must be sent before an acknowledgement must be received.

It just happens that in both my example and Rene’s example, the window size was very small, so only one segment was necessary to exhaust the window. That is why it seemed that the sequence number was directly related to the window size.

One more thing is very confusing to me. In Rene’s tutorial, he is saying “H1 has setup a connection with H2 by using the 3 way handshake. We are sending 10 bytes of Data which means our “window size” is 10 bytes. The sequence number is 10”, but in your example even though when Left device is sending the first chunk of data of 10 bytes, still the sequence number is 1. I am not sure why. Would you please explain it to me?

When beginning a transfer, the SEQ number in the header refers to the first byte that is being sent in that specific segment. But you must also keep in mind that the first SEQ number is always generated randomly, so it can be anything between 0 and something over 4 billion (32 bits represent the SEQ number). It is possible that @ReneMolenaar is using a random number in that example and it just happened to be 10. This can be confusing, and I can ask Rene to look it over and see if it needs revising.

As for the field in the header that indicates the amount of data, there is no such field per se. However, this can be determined by examining the subsequent SEQ numbers in each received segment. Also, when the segments are received on the other end, at the end of the current window, the ACK number that is returned indicates the next expected byte, which in essence reveals the size of the last segment.

I hope this has been helpful!

Laz

2 Likes

Hello Laz,
GREAT EXPLANATION. THAT IS SPECTACULAR.
I have one more little question. I will refer to the below example. When we look at the wireshark capture, does it show us the complete breakdown segment by segment/ packet by packet? My understanding is it does not show segment by segment/packet by packet. I just see host A is sending some data to host B with sequence number 1 in line number 1 and right after that line, host B sends an acknowledgement with 7001. It is not possible to send 7000 bytes in one segment/packet since the MTU is 1500 bytes. Is it? How does wireshark work to show information about communication?

Segment 1: SEQa = 1, Window Size = 7000, segment size = 1500 Bytes
Segment 2: SEQa = 1501, Window Size = 7000, , size = 1500 Bytes
Segment 3: SEQa = 3001, Window Size = 7000, , size = 1500 Bytes
Segment 4: SEQa = 4501, Window Size = 7000, , size = 1500 Bytes
Segment 5: SEQa = 6001, Window Size = 7000, , size = 1000 Bytes

Acknowledgement from Host B to Host A: ACKb = 7001

Thank you so much.

Azm

Hello Azm

When looking at a wireshark capture and you want to record a situation where you would have a window size that is much larger than a segment size, you have to generate traffic that will give you that result. Most idle traffic on your PC will generate segments that are very small. So sessions are opened that will essentially send only one segment. Window size scaling does not come into the picture at all in those cases.

I suggest you generate traffic by sending a large file either via SMB or FTP so that window sizes will increase and be significantly larger than the segment size. In this case, you will see something like this:

I copied a large file from a NAS drive I have (192.168.10.210) to my PC (192.168.10.70) and this is what wireshark captured. Notice that between each acknowledgement, there are seven segments each with a size of 1514 bytes including headers. If you take a look at the segments themselves, they each contain 1460 bytes of data. The Info column states that each one is a segment of a reassembled Protocol Data Unit (PDU is the generic term of the unit of data at each layer of the OSI model,). So the transport layer PDU is the whole “window-sized” chunk of data that is separated into segments.

Try it out and see what you get.

I hope this has been helpful!

Laz

Hello Laz,
I have done some experiment where I was downloading some file from a site. Pretty much everything is clear to me so far. However, couple more questions have popped up. I am going to refer to the below screenshots for my questions.

<img

1. If we look at the first highlighted line in yellow, it has two fields, window size value and calculated window size. What are the differences between them?

2. As we know, window size will keep on going up until the receiver is unable to handle all the packets sent by the sender. How do two hosts let each other know what the window size will be for the next transmission( set of segments)?

3. If we look at the second highlighted line. It has two fields related to window size(window size value=11 and calculated window size=2816) and the acknowledgement of 10441937. I am not sure which one refers to the actual window size. What would be the window size 11 or 2816? However, after the second highlighted line, the sender has sent one packet of 1460 bytes to the receiver 192.168.1.9. Right after that, the receiver sent an acknowledgement to the sender of 10443397. So, that makes sense because 10443397-10441937= 1460 which is the payload, but that 1460 bytes does not match window size(11) and calculated window size(2816) either. Would you please explain it to me?

4. Let’s say in a communication, two hosts have agreed upon a window size 400 bytes. Then the sender sent four packets to the receiver successfully. Isn’t the total of those four packets supposed to be 400 bytes?

window size 400 determined.
100 bytes-------------------------------->
100 bytes-------------------------------->
100 bytes-------------------------------->
100 bytes-------------------------------->

total of four packets =400 bytes

then the receiver will send an acknowledgement of 401. Am I correct?

Thank you so much for your endless help.

Azm

Hello AZM!

Take a look at the third field below the two you indicated: Window size scaling factor: 256. If you’ll notice,

Calculated window size = Window size value * Window size scaling factor If you do the calculations, you’ll find that 256*28=7168. It is this Calculated window size that is the window size that is actually used in the transmission.

Now this goes beyond CCNA or even CCNP as far as I can remember, but it’s good to know. Take a look at the TCP header:

The TCP window size field is 16 bits in length, so the maximum window size is 2^16 = 65536. In modern networks, window sizes can be much larger than this. Within the optional data field, an additional field of 24 bits called windows scaling factor has been added as a multiplier to increase the maximum window size. This was added in a subsequent version of TCP (and is fully used today) and can be found in RFC 1323.

The window size is determined by the receiver. It is the acknowledgement that is sent back to the sender that requests changes in size to the window. Rene describes this well in his lesson for TCP Window Size Scaling.

Like I said for question 1, it is the Calculated Window Size that is the size of the window used. In order to see that the window size matches the number of bytes sent before an acknowledgement, you must also be sure that the captured segments have reached the destination successfully. You may be looking at a segment that had an error and was resent, so the window sizes don’t match up. Look through the captured data to find a clean window so to speak. Because I cannot see details of all the segments of your screenshot, I am unable to be clearer for this question. Sorry!

Yes, you are exactly correct assuming that the maximum segment size allowed on the network is 100 bytes.

I hope this has been helpful!

Laz

Hello Laz,
Once again SPECTACULAR. Thanks for your great help.

Azm

1 Like

Hi,he interface gets congested and packets of all TCP connections are dropped
But the interface utilization is not high .
Can you explain
Thanks

Hello sims

This could be many things. Here are some questions you should ask yourself:

1. You say the interface gets congested. How do you know this? If utilization is not high then it is not congested. The TCP segments must then be dropped for other reasons.
2. Are ALL TCP connections dropped? Are the dropped from the beginning or after a session has begun? If they are dropped from the beginning, then check Access Lists that may be blocking ports.
3. If they are not dropped from the beginning, when are they dropped? After a certain event? What event could this be?

You need to be able to look at more information about the circumstances surrounding the problem, when it occurs and what kinds of sessions are being dropped.

I hope this gives you a little more guidance as to how to troubleshoot. Please share your results with us so we can continue to help you out in determining the problem.

I hope this has been helpful!

Laz