Windows 10 spurious fast TCP retransmissions due to dupACK

Question

Hi,

I have a machine (A) running Windows 10 Enterprise 2016 LTSB that is sending TCP data with a relatively high throughput (600 Mbps) to an other machine (B) via some cross-connected switches and firewalls.

I have issues with the throughput, where sometimes it drops and then recovers. In order to troubleshoot I did some traffic (Wireshark) recordings in A and I could see that the following sequence of events where continuously repeated (around 10 times per second in average, but not periodic, just randomly).

1- A dupACK (with SACK option) is received from B for a specific ACK sequence number.
2- A new ACK is received from B with an higher ACK number. I understand that this new ACK already acknowledges the packet missing before (probably received out of order).
3- The machine A re-transmits the packet with sequence number equal to the ACK sequence number from the dupACK/SACK received in point 1.

From my understanding, the machine A is not behaving as it should since:

• It is not waiting till receive 2 dupACKs before the re-transmission. (Specified in the TcpMaxDupAcks parameter in the following key registry: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, being the default value 2)
• Why machine A is retransmitting the packet if B already sent an ACK with sequence number higher?

This retransmissions decrease the TCP congestion window to the half as part of the congestion avoidance algorithm, and if they happen close one after each other, the overall throughput is affected.

In one of the tests I changed TcpMaxDupAcks parameter from 2 (default) to 3, but the retranmissions where not reduced. No change at all.

Can someone help me to understand the behavior of the machine A? I've attached some printscreens of wireshark, hope they are properly uploaded.

Thanks in advanced,
Joan

Answer 1

Hello Joan,

This problem seems to be increasingly widely recognized by Windows users, but the response from Microsoft is slow.

For some time, the Microsoft TCP congestion algorithm has been moving away from simple "dup ack" counting to RACK-TLP Loss Detection (RFC 8985). The weaknesses in the early implementations seem to be acknowledged (for example, in this link: https://techcommunity.microsoft.com/t5/networking-blog/algorithmic-improvements-boost-tcp-performance-on-the-internet/ba-p/2347061), but the first major upgrade only appeared in Windows 11 (not retrofitted in Windows 10).

Unfortunately, this upgrade also seems to be buggy (see https://gary-nebbett.blogspot.com/2022/01/windows-11-tcpip-congestion-control.html).

The "apparent" retransmitting of data after it has been acknowledged is just an artefact of the packet capture/tracing process and multithreading: the retransmit is initiated/queued before the acknowledgement has been processed by the TCP stack.

Gary

Answer 2

Hi Garry,

Thanks for your quick reply! My machine A has an OS version 1607 and OS build 14393.2515, which seems to be severely affected by those packet re-orderings.

I've seen that Dropbox did some interesting troubleshooting with Windows regarding the same issue: https://dropbox.tech/infrastructure/boosting-dropbox-upload-speed
They mitigated the number of re-orderings disabling their Intel NICs feature called “Application Targeted Routing (ATR).".

I understand that is not till Windows 10 build 21332 that Windows implement the RFC 8985 you mentioned.

Thanks again,
Joan