TCP Window Scaling Not Working Between Windows 10 and Linux Server

by

We are having some issues with several clients running Windows 10 downloading files from our HTTP file delivery server.

We can’t reproduce the error on our end but notice that TCP window scaling is not “ramping up” and throughput between the Linux server and Windows 10 client remains low.

We have run a TCPDUMP on the server capturing packets from the client and can see the small window size:

Example:

00:00:00.321292 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:564401}], length 0
 00:00:00.321348 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:565761}], length 0
 00:00:00.321359 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 590241:591601, ack 702, win 30, length 1360: HTTP
 00:00:00.322417 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:572561}], length 0
 00:00:00.322482 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:573921}], length 0
 00:00:00.322497 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 595681:597041, ack 702, win 30, length 1360: HTTP
 00:00:00.322528 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:575281}], length 0
 00:00:00.322559 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 597041:598401, ack 702, win 30, length 1360: HTTP
 00:00:00.322570 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:576641}], length 0
 00:00:00.322983 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:578001}], length 0
 00:00:00.323007 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 598401:599761, ack 702, win 30, length 1360: HTTP
 00:00:00.323015 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 554881, win 1025, options [nop,nop,sack 1 {556241:579361}], length 0
 00:00:00.323026 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 599761:601121, ack 702, win 30, length 1360: HTTP
 00:00:00.323268 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 587521, win 1025, length 0
 00:00:00.332204 IP 85.144.19.44.58799 > 195.224.144.66.80: Flags [.], ack 591601, win 1025, length 0
 00:00:00.332242 IP 195.224.144.66.80 > 85.144.19.44.58799: Flags [.], seq 606561:609281, ack 702, win 30, length 2720: HTTP

Notice the small window size (1025).

We have tested the Windows 10 client throughput using another server on our network (macOS) and can get full throughput along with increased scaling window sizes so the problem seems to be this specific to this Linux server.

We have made some changes to the network stack on this particular Linux server which we include in sysctl.conf:

kernel.panic = 3
net.core.somaxconn = 1024
net.ipv4.tcp_ecn = 0
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_mtu_probing = 1
vm.swappiness = 1
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv6.route.flush = 1

Does anyone have any ideas as to why Windows 10 won’t negotiate better TCP window sizes with our Linux machine? It’s not an issue of middleboxes as stated above, we can achieve full throughput by testing with a different server on our same delivery network. It’s just this particular machine.

Any thoughts, feedback, tips, and advice are greatly appreciated in advance.

Many thanks.

Answer

Attribution
Source : Link , Question Author : Ted Wilmont , Answer Author : Community

Leave a Comment