0

We have a network throughput issue, but cannot find a bottleneck. We have spent four weeks looking at router logs, FW logs, and monitoring and we are now looking into the TCP window size on client.

What I already know from research and do not require an explanation here:

  • What the TCP window does, and is for
  • What happens when it is full
  • How ACKs tell the sender that more buffer is free
  • How TCP Scaling works and this needs to be captured in the 3-way handshake

What I have found is that the TCP window (on any machine) always sets the same value for every session. However, I also found that the same window seems to be a different (almost unique) to each machine.

I know that some of this is due to the OS, but is this "buffer" a space on the NIC or the RAM in OS?

Does additional RAM equate to a larger window size?

What factors determine the "negotiated" window size?

I know congestion control can play a part in this, but my Wireshark captures are setting these values right at the beginning of the TCP handshake, so I can't see how any form on congestion control is in play this early on.

Another point I'd like to make is that the receiver window never decreases when the sender sends lots of data. For example, let's say the receive window is 2 MB. I read that when bytes are in flight (no ACK received yet), that the advertised window should start to decrease. This is not occurring, the receiver keeps sending back ACKs with the same window size, even though it has not ACKed all bytes in flight yet.

Is this normal or have I misunderstood what I read?

Mucker
  • 375

1 Answers1

1

What I have found is that the TCP window (on any machine) always sets the same TCP window.

Initially, that might be true. However, the windows size is a dynamic value, constantly adjusted to detected bandwidth and congestion.

I know that some of this is due to the OS, but is this "buffer" a space on the NIC or the RAM in OS?

It's in memory, controlled by the network stack (part of OS).

Does additional RAM equate to a larger window size? What factors determine what the "negotiated" window size is?

No. The window size is adjusted according to the calculated available bandwidth in the connection. There's a quite complex model behind that as outlined in Wikipedia.

I know congestion control can play a part in this, but my Wireshark captures are settings these values right at the beginning of the TCP handshake

Look again. There's an initial value and there are frequent updates to that value.

Another point I'd like to make is that the receiver window never seems to decrease when the sender sends lots of data.

The window size doesn't depend on the amount of data sent but on the detected effective bandwidth.

For the underlying "network throughput issue", the window size is likely an X/Y problem. I'd suggest opening a new question with sufficient detail of your actual problem (how does it look and when did it start?) and on your network setup: a diagram, models and configurations of relevant devices, things you've already tried and odd observations that you might have made. With a proper description and on-topic devices your new question should be well suited for Network Engineering.

Zac67
  • 13,684