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.
asked 22 Jan '13, 12:08  Dodgyrabbit edited 24 Jan '13, 08:22 |
3 Answers:
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:
answered 23 Jan '13, 13:21 Dodgyrabbit |
"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 ♦♦ |
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..
Regards answered 22 Jan '13, 16:14  Kurt Knochner ♦ 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 ♦ |
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.