1

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

enter image description here

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!

Improve this question
2
  • Are you forgetting that TCP connects two peers, both of which are capable of sending and receiving, and that the window sizes can be different for each direction?
    – Ron Maupin ♦
    Jan 12, 2018 at 3:52
  • @RonMaupin No, I am well aware of that. My question was different. In the same host I am observing that the window sizes announced in SYN segments is (several orders of magnitude) different from that announced in the following segment.
    – rutex
    Jan 12, 2018 at 8:11

1 Answer 1

Reset to default
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.

Improve this answer
7
  • Thank you for response. Do you have any idea what influences the selection of the actual window size? I mean if the buffer (i.e., maximum window size announced in SYN) is 2MB, what is the algorithm that TCP uses to decide that the next advertised window size is 131744 bytes (90 MSS)? Is this hardcoded in the OS?
    – rutex
    Jan 12, 2018 at 8:25
  • The maximum buffer size is often configurable somewhere within the OS (via registry setting in Win, not sure about *nix). The actual window size as I mentioned in my answer is the result of multiple complementary (or sometimes competing) calculations/algorithms and it is often not easy to discern based solely on external packet captures. Different OSes, and even different versions or flavors of the same OS, perform TCP windowing differently. You can take it up as an entire field of study (I have read multiple post-graduate theses related to the subject).
    – halfmetaljacket
    Jan 12, 2018 at 8:33
  • For future reference I will say that in OS X (at least newer versions) the receive buffer size is defined by the "net.inet.tcp.autorcvbufmax" sysctl variable. However, there is no such variable for the actual window size before the OS has information enough to determine the window size based on congestion and so on... at least I couldn't find it
    – rutex
    Jan 12, 2018 at 8:38
  • It's also worth noting that individual applications can even implement their own custom TCP windowing to some extent, really throwing you off when troubleshooting complex network issues.
    – halfmetaljacket
    Jan 12, 2018 at 8:39
  • Thank you! You were very helpful. TCP is rather complex and it is always good to hear from the experts :-)
    – rutex
    Jan 12, 2018 at 8:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.