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

TCP Retransmits on Windows Server for slow connections

0

I'm trying to understand why there are seemingly 'aggressive' TCP retransmits seen in the capture below:

The server is a Windows 2008 R2 server, the client is connecting over a "slow" GPRS or 3G connection. Notice how the server will retransmit packet number 5 after 0.36s and then again after 0.6 seconds. Doubling the timeout (this seems to be consistent with some logic built into how TCP calculates the retry timeout).

It's almost as if the server "thinks" the connection is faster then it really is. This pattern continues throughout the session.

Any thoughts or comments appreciated.

alt text

Direct link to image

asked 22 Jan '13, 12:08

Dodgyrabbit's gravatar image

Dodgyrabbit
1113
accept rate: 100%

edited 24 Jan '13, 08:22


3 Answers:

0

We have found the solution. Windows 2008 R2 has an issue where the RTT is not recalculated under some specific conditions related to SACK and high latency networks. We have confirmed that enabling this setting fixes the problem and RTT is correctly updated, therefore stopping the premature retries:

netsh interface tcp set global nonsackrttresiliency=enabled

TCP packets sent from Windows Server 2008 R2 are retransmitted when SACK is disabled on the client computer

KB 2764305

answered 23 Jan '13, 13:21

Dodgyrabbit's gravatar image

Dodgyrabbit
1113
accept rate: 100%

0

"Slow connection" is a bit of a nice way putting it... it is crawling with hands and knees on a floor pasted with sticky tar - the RTT is almost 1 (in words: one) second :-)

I guess the server really gets impatient after a while in packet 6, and while it should have noticed that the three way handshake was indeed almost taking one second it retransmitted faster than that. The initial Retransmission Timeout for Windows Server 2k8R2 is 3000 milliseconds, for SYN and the first data segment. So I think it should have waited longer, but it is possible that packet number 4 (arriving quite soon after packet number 3) fooled the stack into believing that there is now a much better RTT. Or it is just refusing to believe that a connection could be THIS slow :-)

On a sidenote... there is a ongoing quest for my coworker @landi and me to track down a Microsoft engineer to find out what the Windows stack really does, and why. So far, no technical personal was ever able to answer questions like that, so unless we find the guy who writes the stack code we'll keep guessing... :-)

answered 22 Jan '13, 12:41

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

On a sidenote... there is a ongoing quest for my coworker @landi and me to track down a Microsoft engineer to find out what the Windows stack really does, and why.

hahaha... funny ;-)) I'll donate a bottle of champagne, if you ever find a single person who is able to give really detailed insight into the internal workings of the stack of a certain patch level.

(22 Jan '13, 15:24) Kurt Knochner ♦

0

It's almost as if the server "thinks" the connection is faster then it really is. This pattern continues throughout the session.

maybe it's not the 2008 R2 stack, but the TCP offloading code of the NIC driver, who is a bit 'optimistic' while calculating the RTO ;-) Please check if TCP offloading (chimney) is enabled. If so, please disable it and retry..

http://wiki.wireshark.org/CaptureSetup/Offloading#TCP_Chimney
http://blogs.technet.com/b/brad_rutkowski/archive/2007/08/10/how-to-know-if-tcp-offload-is-working.aspx
http://support.microsoft.com/kb/951037

Regards
Kurt

answered 22 Jan '13, 16:14

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thanks Kurt - didn't think of that. I had a look and the TCP offloading is set to automatic. However, there are no connections that are in the offloaded state.

(23 Jan '13, 05:58) Dodgyrabbit

Never trust any stats ;-) Did you try to disable it?

(23 Jan '13, 10:57) Kurt Knochner ♦