TCP send window, receive window and how they work

The chart above is a snapshot taken from the sender's perspective. We can divide the data into 4 groups:

• Bytes sent and acknowledged (blue)
• Bytes sent but not yet acknowledged (yellow)
• Bytes that have not been sent but are ready to be received by the receiver (green)
• Bytes that have not been sent and that the receiver is not ready to receive (grey)

Class 3 is also called the available window because this is the window that the sender can use.

The send window includes the yellow and green parts. These bytes have either been sent or can be sent.

1*OqqxQKu4ZGasXzIlUZ9lyw.png

The available window may be empty when the sender has sent 21-25 bytes and used all bytes in the available window. The send window remains unchanged.

1*JdTCgvYpVPRDcLyVb8Rwsg.png

When the sender receives an acknowledgment for bytes 16-19, the send window slides 4 bytes to the right. The next bytes in the queue will have a newer available window.

1*9zFu_scvenahSK6m-khSjw.png

Some definitions may help us better understand the complexities that follow in this article:

• SND.WND, indicating the send window
• SND.UNA, indicates the send unconfirmed pointer, which points to the first byte of the send window
• SND.NXT, which means sending the next pointer, pointing to the first byte of the available window

1*IYBc3_OiPWAZ7JCvIaktkA.png

Based on these definitions, we can express the size of the available window as follows.

Receive Window

1*SbgJAvyVKyXYvPLuoBbGtA.png

The receive window is divided into 3 categories:

• Bytes received and acknowledged
• Bytes not yet received but allowed to be sent by the sender
• Bytes that have not yet been received and that the sender may not allow to be sent

The second type is called the receive window, which can also be called RCV.WND.

Similar to the send window, there is a pointer RCV.NXT, which represents the first byte of the receive window.

1*u3KoxvVK-rrM1g4gX6fbZQ.png

The receive window is not static. If the server is running efficiently, the receive window can expand. Otherwise, it can shrink.

The receiver communicates its receive window by indicating the size in the window field in the TCP segment header. When the sender receives it, this window size becomes the available window.

Sending and receiving segments takes time. Therefore, the receive window is not equal to the available window at a particular moment.

Simplified example

Let's simulate a request and response to better understand how the sliding window works.

There are two modifications that simplify our calculations.

• We ignore the Maximum Segment Size (MSS). The MSS varies depending on the network routing chosen.
• We make the receive window equal to the available window and keep it constant throughout the process.

1*sAF4A2TyNeItzw2yK0xI9g.png

Above is a diagram showing an example of 10 steps.

The client requests a resource and the server responds with three segments:

• 50 bytes header
• 80 bytes of text part 1
• 100 bytes of body part 2

Each party can be both a sender and a receiver at the same time.

We assume that the client's send window (SND.WND) is 300 bytes and the receive window (RCV.WND) is 150 bytes. Therefore, the server's SND.WND is 150 bytes and RCV.WND is 300 bytes.

1*cU9TEaEoezDwvw__3G1DFw.png

This is the starting state of the client.

We assume that it has previously received 300 bytes from the server, so RCV.NXT points to 301.

Since it hasn't sent anything yet, SND.UNA and SND.NXT both point to 1.

1*IYBc3_OiPWAZ7JCvIaktkA.png

According to this formula, the available window size for the client is 1 + 300 - 1 = 300.

1*kfa6ZdhSR_VJggJ2abUSAQ.png

This is the starting state of the server, reflecting the state on the other side.

Since it has sent 300 bytes, both SND.UNA and SND.NXT point to 301.

Since the client has not sent any request yet, RCV.NXT points to 1.

The server's available window is 301 + 150 - 301 = 150.

Now, step 1 begins.

The client sends the first 100 bytes of the request. At this moment, the window changes.

• These 100 bytes have been sent but not yet acknowledged. Therefore, SND.NXT slides 100 bytes to the right.
• The other pointers remain unchanged.

The available window becomes 1 + 300 - 101 = 200.

1*ug0laVIMWQ3HGG-kPjZ0KA.png

In step 2, we focused on the server.

• When the server receives the request, RCV.NXT slides 100 bytes to the right.
• Then a 50 byte response with an ACK is sent. These 50 bytes have been sent but not yet acknowledged, so SND.NXT shifts 50 bytes to the right.
• SND.UNA remains unchanged.

The available window becomes 301 + 150 - 351 = 100.

1*GAZqLwbVGj2yqUnm5DyI4w.png

Move to the client.

• When the client receives the 50-byte response, RCV.NXT slides 50 bytes to the right.
• When it receives an ACK for the 100 bytes sent earlier, SND.UNA slides to the right.
• Since the client did not send any data, SND.NXT remains unchanged.

The available window becomes 101 + 300 - 101 = 300.

1*50UitYxS9XW3N4XV2Z7tOg.png

Move to the server side again.

The available window is 100 bytes. The server can send segments of 80 bytes.

• SND.NXT slid 80 bytes to the right.
• Since the previous 50 bytes have not been confirmed, SND.UNA remains unchanged.
• Since the server is not receiving any data, RCV.NXT remains unchanged.

The available window becomes 301 + 150 - 431 = 20.

1*soNJeyvqRj0zqDDrtBL9Fg.png

The client receives the first part of the file and immediately sends an ACK.

• When the client receives 80 bytes of data, RCV.NXT slides to the right.
• The other pointers remain unchanged.

The available window remains at 300.

1*QJKwuY3HvslR9601ZRWCxA.png

At this point, the server receives an ACK when it sends step 2.

• When the server sent a 50-byte response, SND.UNA slid 50 bytes to the right.
• The other pointers remain unchanged.

1*thuJ7lCYqreqxsL8nMz_ag.png

In step 4, the server sends the first 80 bytes of the file and receives an ACK again.

• SND.UNA (confirmed sequence number) is shifted 80 bytes to the right.
• The other pointers remain unchanged.

The calculation of the available window becomes 431 + 150 - 431 = 150.

1*8sS5S0OkW0I2Vbp40nkkZQ.png

In step 8, the server sends the second part of the file, totaling 100 bytes.

• SND.NXT (the next sequence number to be sent) is shifted 100 bytes to the right.
• The other pointers remain unchanged.

The calculation of the available window becomes 431 + 150 - 531 = 50.

1*qXP9BCX80vPpkplc5utP6Q.png

Next, it's the client's turn.

• RCV.NXT (next sequence number to be received) is shifted 100 bytes to the right after the client receives 100 bytes.
• The other pointers remain unchanged.

The available windows remain unchanged.

1*LkQ7tG-_1XQROjOZ3vTC9g.png

Finally, the server receives an ACK for the previous response.

• SND.UNA is shifted 100 bytes to the right.
• The other pointers remain unchanged.

The calculation of the available window becomes 531 + 150 - 531 = 150.

When the window changes

Earlier, we assumed that the send window and the receive window remain constant. But in reality, this assumption is incorrect because the bytes in both windows exist in the operating system buffer, and the free space in the buffer can be adjusted. When our application cannot read the bytes in the buffer quickly, the free space will decrease.

Let's look at what happens when a window changes and how it affects the available windows.

1*qyjkUdkAdsfrkRkqVlPClw.png

For simplicity, this example focuses on the client's available window. In this example, the client is always the sender and the server is the receiver.

1*u3KoxvVK-rrM1g4gX6fbZQ.png

When the server sends an ACK, it also includes the updated window size.

1*pkiC_TWGpIZF3aSPOz6lcA.png

Initially, the client sends a 150-byte request.

• These 150 bytes have been sent but not yet acknowledged.
• The available window is reduced to 150 bytes.
• The send window remains at 300 bytes.

1*zs4VuHChJJ-7vWFmXyr8Ug.png

When the server receives the request, the application reads the first 50 bytes, and the remaining 100 bytes are still in the buffer, taking up 100 bytes of available space from the receive window. Therefore, the receive window is reduced to 200 bytes.

Next, the server sends an ACK with an updated receive window of 200 bytes.

1*SZDl6q22CB6kzY3P-CCHFA.png

The client receives the ACK and updates its send window size to 200.

At this point, the available window is the same as the send window because all 150 bytes have been acknowledged.

1*6gKYyaDUdOQSEGfHh6SWdA.png

Again, the client sends another request for 200 bytes, using all the available space in the available window.

1*uJiRzHmdV4kT8lPW62bz0g.png

After the server receives these 200 bytes, the application is still slow and has only read 70 bytes in total, leaving 280 bytes in the buffer. This causes the receive window to shrink again, now only 20 bytes are left.

In the ACK message, the server shares the updated window size with the client.

1*xnUjR-R45hPoGO7qhvCHKg.png

Again, after receiving the ACK, the client updates its send window to 20 bytes, and the available window also becomes 20 bytes.

In this case, if there are no more messages from the server, the client will stop sending requests larger than 20 bytes until another window update is received in a subsequent message.

So, if no more messages come from the server, are we stuck with the 20 byte available window?

No. To avoid this, the client's TCP periodically checks the window size.

Once more space is freed,

The available window will be expanded and more data can be sent.

Main content

• The calculation of the available window is the key to understanding the TCP sliding window.
• To understand the calculation of the available window, we need to understand 3 pointers - SND.UNA, SND.NXT and RCV.NXT.
• Assuming that the window size never changes can help us understand the whole process.