This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Why is receive window limited from Linux client?

0

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:

$ sudo sysctl -a | grep rmem
net.core.rmem_max = 2097152
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048510 1048510 16777216

The request is made with wget "http://10.20.30.120:9080/silly_webapp/Silly?fn=output&bytes=131072" and strace does not show any usage of SO_RCVBUF:

socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(9080), sin_addr=inet_addr("10.20.30.120")}, 16) = 0
select(5, NULL, [4], NULL, {900, 0})    = 1 (out [4], left {899, 999994})
write(4, "GET /silly_webapp/Silly?fn=outpu"..., 156) = 156

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's gravatar image

kgibm
16115
accept rate: 0%


One Answer:

2

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...
I would say this is a good/common practice to shield the receiving TCP from a mis-behaving sender that does not follow the slowstart algorithm.
Regards Matthias

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's gravatar image

mrEEde
3.9k152270
accept rate: 20%

edited 30 Oct '14, 00:00

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?

(29 Oct '14, 23:03) kgibm

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.

(29 Oct '14, 23:04) kgibm

The other linux client offering 131328 is also running RHEL?

(30 Oct '14, 00:01) mrEEde

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)?

(30 Oct '14, 06:54) kgibm

Regarding the link you added, are you sure that's about the receiver intial window and not the sender's congestion window?

(30 Oct '14, 07:07) kgibm

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.

(30 Oct '14, 08:00) mrEEde

Thanks Matthias!

(30 Oct '14, 08:16) kgibm
showing 5 of 7 show 2 more comments