pcap uniformly shows bytes in flight greater than receive window. (??)

[jmaxwellUSAF]

While investigating network latency in a Cisco network, a pcap uniformly shows bytes in flight greater than receive window. How can that be possible?

(see picture attached)

Thank you!

[Georg Pauwen]

Hello,

hard to tell why you see this. Which application(s) are sending the traffic ? I think there are techniques like TCP window scaling, which allows for larger receive window sizes. In such cases, the receive window advertised by the receiver may not accurately reflect the amount of data actually received, leading to apparent discrepancies between bytes in flight and the receive window.

[Joseph W. Doherty]

Would need to see PCAP (on my phone at the moment), but @Georg Pauwen's may be correct as RWIN above 64 KB uses a scaling multiplier, i.e. actual RWIN value in packet can be much larger than it appears.

[jmaxwellUSAF · Accepted solution]

I'm confident I found the answer...

[window size scaling factor -1 (unknown)]

Because the pcap does not contain the 3-way handshake, the pcap does not know the window scaling factor, so the output is erroneous.

---

what determines the final windows scaling factor? - Ask Wireshark

"It means that the trace file does not contain the TCP three-way handshake, so Wireshark does not know whether window scaling is in use, and if it is, what the window scaling factor is. If Wireshark sees the three-way handshake, and window scaling is used, Wireshark will know what window scaling factor is used by each side. Wireshark will then calculate the true window size for you by multiplying the value in the window size field by the appropriate multiplier.

If Wireshark does not see the three-way handshake, it will simply report the value of the window size field, which may or may not be the true window size, and indicate "[window size scaling factor -1 (unknown)]"

See RFC 1323 for the specification of the TCP window scale option."

[Joseph W. Doherty]

Yup, large windowing is setup during the 3 way handshake - both sides have to agreed to it.  BTW, with large windowing, selective ACKs (SACK) is often advisable.

Oh, and if you're read up on large windowing, you should see windowing (if I recall correctly) scales from 128 KB to 2 GB, so as I noted earlier, window can be much larger than a 64 KB non-scaled window.

Lastly, although you noted investigating high latency, once you start to scale up the window size, again, selective ACKs can become somewhat important.