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

Initial tcp.window_size_value / tcp.window_size_scalefactor

0

Hi,

I have read RFCs 2001, 1323 + 2414 as well as a lot of other sources inc. packetlife, ask wireshark and google etc.. But I cannot figure out why a computer is sometimes giving Window size value of(i.e.) 237 and a WSS(i.e.) of 128 and other times a Window size value 16028 and a WSS of 4.

I am assuming / guessing / interpretting that it has to do with the bandwidth delay product as it seems small WSV and large WSS on low latency and large WSV and low WSS on high latency. I can figure out why a window is sometimes 64k to start and sometimes 4k, but I cannot find any Information up to now of how the value*scale is worked out? Would be very much appreciated if someone can point me at the right RFC or explanation somewhere.

asked 05 Oct '14, 12:01

DarrenWright's gravatar image

DarrenWright
216141520
accept rate: 26%


2 Answers:

0

ahahahaha "NEVER GIVE UP, NEVER SAY DIE"

for Windows 7 missing TCP Stack selections find these KBs: KB2861819 + KB2472264

netsh interface tcp set global initialRto=1000 (500 to 3000*is default. 500 causes retransmissions if your RTT is high) netsh interface tcp set global timestamps=enabled netsh interface tcp set global congestionprovider=ctcp netsh int tcp set heuristics disabled

Now you can workout roughly what size of Windows will be used to ensure the best use of the Line: Low latency High BW = small window size * large WS multiplier High Latency Low BW = Larger window size * small WS Multiplier

If you are on WIndows 2008R2 or Windows 8 you can even manually edit the Initial CWIN Multiplier (>16)

netsh interface tcp set supplemental template=custom minRto=20 icw=16 delayedacktimeout=10 netsh interface tcp set supplemental template=custom

With a little fine tuning you can rip your download speed in Windows to almost the maximum

I know the thread is old, but I couldn't believe how anoyying this information is to piece together... And Tip: Disable mscc Windows service + dependency on Audio Service. It really screws with your retransmissions...

answered 20 Dec '14, 14:41

DarrenWright's gravatar image

DarrenWright
216141520
accept rate: 26%

Thanks for the formatting Graham. Still haven't quite got the hang of it :/

I have deleted my old answer as some of the information there was, following testing, found to be not 100% relevant.

I have been testing this now for a few days under windows 7(x64) SP1 with the settings above. I am seeing far fewer retransmissions and my download speed is almost always maxed out now on my dsl 16k. The window sizes are also now somewhat more predictable.

(21 Dec '14, 23:06) DarrenWright

0

The scale factor is determined by the TCP stack. Sometimes it uses specific values (e.g. Vista used a scale factor of 2^8 = 256 and set the window size value to 256), sometimes it is based on some heuristics.

The stack in Windows 7 and up even tells you that it has a "Receive Window Auto-Tuning Level". You can check the current setting with the command "netsh interface tcp show global" on a command prompt. If you check the available settings it shows

autotuninglevel - One of the following values:
                         disabled: Fix the receive window at its default
                             value.
                         highlyrestricted: Allow the receive window to
                             grow beyond its default value, but do so
                             very conservatively.
                         restricted: Allow the receive window to grow
                             beyond its default value, but limit such
                             growth in some scenarios.
                         normal: Allow the receive window to grow to
                             accomodate almost all scenarios.
                         experimental: Allow the receive window to grow

As far as I found out, experimental sets the scale factor to 2^14 (maximum) which allows scaling to about 1 GByte. "Disabled" does just that - no more scaling.

What the stack does is setting scale factors that allow it to set the receive window to values that are big enough for it's puposes. E.g. with Vista, it could scale the Window from 256 (actually, 0, but that's a full stop) to 16MB (256 * 65,535), but of course only in steps of 256 bytes.

BTW, the Windows stack will also tell you this: "** The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any local/policy configuration on at least one profile." - and there is no documentation (AFAIK) that shows how that heuristics work.

answered 05 Oct '14, 12:48

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

edited 05 Oct '14, 12:49

this is why I am confused. Heuristics is disabled. Tuning (aka Scaling..) is Normal. So, why does it vary, without heuristics I would expect it to always go for 2^8 * 256? I can connect to one site and get a wss of 256, on another 4. I can get a Window size value of 128 or a window size value of 65535.. What gives? Funnily enough as I write this I realise I have never seen anything less than 4 from my client?

(05 Oct '14, 13:07) DarrenWright

I don't think you can actually disable the heuristics except if you set autotuning level to disabled... btw., I have even seen that turning Antivirus softwares on and off can have an effect on the scaling...

(05 Oct '14, 13:09) Jasper ♦♦

netsh int tcp set heuristics disabled

Apparently (and I cant be sure. WIndows 7 stack is (with heuristics enabled) doing it's upmost to hold your rwin at 256k.

If you disable Heuristics, it can grow normally apparently. I would have to play around here to see what is happening..

BUT. My question still remains. Windows decides on an Initial Window of 66052(for ease of Maths..) Why is this windows sometimes made up as 16513 Window_Size_Value with Scalefactor 4 And other times made up of Window_Size_Value 256 and Scalefactor 256. On the same stack. Talking to the same host. Could this be a switch or other path object laughing at me?

(05 Oct '14, 13:27) DarrenWright

Well, you'll not get an answer, because Microsoft doesn't tell - many of us have tried :-)

(05 Oct '14, 13:28) Jasper ♦♦