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

Windows 7 TCP Window “Auto-Tuning”

0

As far I know (have just red to be honest :-) ) Windows 7 TCP stack has "Auto-Tuning" functionality which one in particular has following property:

The idea is, a small initial RWIN value is advertised, which is then adjusted on the fly depending on the current line speed and latency. ….//…

I am very interested in this – cos using 3G connection with increasing latency I got sharp fall of TCP downloads speed, so I perform few tests: TEST 1.

alt text

I performed same test few more time and in most cases I got same results – latency increased during transmission and then sharp fall of TCP downloads speed, cos sender instead of sending more segments has to wait for ACKs from receiver. Window size increase can solve this, I suppose, but as you can see Receive window stay constant – 17680 bytes, what is small for 3G connection. But another day I performed tests again and got another condition – stable high download speed without falls and spikes, I checked Wireshark, and saw following:

alt text

As you can see after delay had increased ( what had resulted in TCP window full message in dump - cos no ACK received during window) receiver adjusted window from 17680 to 243440 bytes! And download speed didnt suffer.

Can somebody help me to understand why behavior is so different and why? I cant find in what is difference between downloads.

P.S. Ftp server, Ftp client and mobile network operator are same in all tests.

P.S2. Here is more, btw filtered to contain only one ftp transfer session and partially - https://www.cloudshark.org/captures/a04f219f963a - steady transfer with adaptive window on fly https://www.cloudshark.org/captures/a771a2dfa12d - rough transfer with persistent window

asked 01 Jun '15, 03:52

mongolio's gravatar image

mongolio
21459
accept rate: 0%

edited 01 Jun '15, 09:34


One Answer:

1

Those screen shots are not really helpful as you cut away the IP addresses, so tracking packet direction is harder than it should be. Also, the three way handshake is important (and missing) to determine options and iRTT. Next time try to include all columns, or better yet, provide a capture file. Sanitize it with TraceWrangler if necessary.

On a side note: don't try to figure out what Autotuning does - most (all) of us who tried failed. There is no official (or even unofficial) information from Microsoft what their stack is doing, and when. It behaves totally different in various situations. Even things like Antivirus software has an impact. Maybe the receiver had enough memory when it pulled up the window and didn't in the other situation. Everything in modern computers depends on each other, so it's really hard to track behavior like that of the TCP stack.

answered 01 Jun '15, 07:19

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

or better yet, provide a capture file

Just added partial capture files to first post.

On a side note: don't try to figure out what Autotuning does - most (all) of us who tried failed.

It is not my scope to figure out what Autotuning does but I have to find out in which conditions i can have steady download speed. Cos for me all download attempts looks rather similar - same PC, same ftp server, same Node-B, same distance from Node-B, same QoS levels in mobile network, same load on RF channels during tests and so on, but nevertheless in most cases I got poor performance with falls and spikes of traffic.

(01 Jun '15, 09:53) mongolio
1

Okay, but determining steady download speed conditions is easy (well, relatively) if you have a capture - just find out what slows you down. There's basically two issues that you'll face: packet loss, and window size too small. For a good analysis you'd need captures taken at the same time both at client and at the server to be able to compare what the situation for each node was.

Problem is, that it is really hard to tell why a system used a specific window size since we have that funky auto tuning stuff these days. It was a lot easier back when we all ran Windows XP and earlier :-)

(01 Jun '15, 10:17) Jasper ♦♦

Jasper, as I red about Windows (OS) TCP realization it can use latency not only as signal to increase window size, but also as a signal to decrease window size to avoid upcoming congestion. Do you have any assumptions by what means does it derive when latency caused by changing transmission environment (when latency increased but there are no congestion) and when latency increased due to links utilization?

(02 Jun '15, 09:39) mongolio
1

No idea; that's in the realm of the mystical magic of the Windows TCP stack. It does what it does, I've given up to try to figure out why :)

(02 Jun '15, 10:23) Jasper ♦♦