Capture: https://www.cloudshark.org/captures/1d1eeadf0ad5 Configuration: Client (Linux 2.6.32-431.30.1.el6.x86_64) --> HTTP GET --> Server (Linux 3.16.6-203.fc20.x86_64) The receive window sent by 10.20.30.254 is no more than 14848; however, the client is configured with:
The request is made with
Why isn't the initially advertised receive window larger? (I'm investigating an issue where a large response is being delayed and this is the first symptom I noticed.) asked 29 Oct '14, 22:37 kgibm |
One Answer:
This is the first offering of the windowsize after the 3-way handshake. It allows for 10 full sized MSS segments. The windowsize will/should open up as the session goes on - if it ever does... Just found this link http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-00 explaining the 10 MSS . answered 29 Oct '14, 22:53 mrEEde edited 30 Oct '14, 00:00 showing 5 of 7 show 2 more comments |
Thanks. I have a different packet capture (which I can't share) where a Linux client advertises a window size of 131328 in the first offering - how is that possible? Is it possible to change the 10 value?
I should add that the final use case will be a completely internal network with controlled software, so a mis-behaving sender is not a concern and we want to maximize throughput.
The other linux client offering 131328 is also running RHEL?
Good question, it looks like it is actually Windows 7. Does that have a different first offering size? Or maybe the MSS is bigger (e.g. jumbo frames)?
Regarding the link you added, are you sure that's about the receiver intial window and not the sender's congestion window?
The change specified in this document affects the value of the initial window. So I interpret as being the receiver's initial windowsize.
Windows and Linux use different TCP stacks and thus operate differently.
Thanks Matthias!