Calculated window size value in SYN segment differ from calculated value in ACK segment

Question

I am a bit confused about the window size value in some TCP segments. I think I understand the theory behind the window size field and how it is modified when the window scale option is provided during connection establishment. But I was inspecting the following TCP flow

and realised that something was not clear to me. I will show it to you:

[SYN] Win=65535 WS=32

Which means that the actual window size is 65535*32 = 2097120. However, after receiving the SYN+ACK segment, the device responds with

[ACK] Win=131744

which in fact is the calculated value, obtained from multiplying the value of the window size field (4117) by the WScale announced within the SYN segment (i.e., 2^5 = 32).

And something similar happens with the window size field announced by the other party:

[SYN, ACK] Win=28960, WS=128

which results in a calculated window size of 3706880. However, the 5th segment of the flow is announcing a calculated window size of just 30080.

---

Since the windows values announced in SYN segments are much larger than those in subsequent segments, I want to believe that the SYN segment is somehow announcing the total buffer size (i.e., the maximum window that it could be announce) while the ACK segment is announcing how much it is willing to accept for now. So, in some sense, the device is telling its counterpart that at some point in the future it might increase the advertised window.

Can anyone tell me wether I am right on this reasoning?

Thanks in advance!

Answer 1

Your reasoning is correct, more or less. The window scale value for each side can only be set once, in the SYN packet at the beginning of the TCP session, and thus sets an upper bound to the window size (66536 x WS) that can be advertised by that receiver. For this reason, it is in the receiver's best interest (if throughput is a desired feature of the session) to set the largest possible WS value that its buffer can handle in order to maximize throughput during the TCP session.

However, there are multiple other algorithms and factors that play into what window sizes values are actually advertised, particularly at the start of a session. These include TCP slow start, TCP congestion control (e.g. additive increase multiplicative decrease), Nagle's algorithm, etc. Since TCP windowing is one of the primary methods for balancing throughput, controlling congestion, and endpoint resource utilization, a lot can go into actual advertised TCP window sizes.