TCP Retransmits over industrial network

edit

Hi,

this is a mismatch between the Windows Client and the Windows Server and belongs to the TCP Profile used for the traffic.

But please note: This retransmissions does not have any impact and seems to be not responsible for the issues you notice!

These specific retransmissions are cosmetic issues.

I would recommend to record the traffic in exact those times were you have the issue. Also 1:40 Minute of traffic is not enough to recommend anything.

Why this happens: The Server is using, im sure, a datacenter profile sending traffic, where the RTO (Retransmission Timeout) is very low at 20ms. The Client is using the Internet Profile with very conservatives settings, where the Delayed Ack is set to 200ms and min RTO with 300ms.

Therefore, the server is sending Payload to the client and uses the own RTO of 20ms. That means, if no ACK is seen after 20ms, it retransmits the packet. The Client itself is receiving the packet and the TCP Stack waits the Delayed ACK timer for the ACK (max 200ms), because there may be an answer from the application and the ACK + answer can be send in the same frame. So the client tries to prevent sending 2 frames and this for max 200ms (Delayed Ack Timeout).

So the RTO of the Server undergoes the delayed ack timer of the client.

Why the client mostly answers fast and sometimes not is unclear at the first look.

You can check available profiles at both systems with:

Powershell get-nettcpsetting

Also you can check which tcp connection is using which profil: powershell Get-NetTCPConnection

and additional you can see which filter is used to decide which profile shall be used for a specific connection: powershell Get-NetTransportFilter

Please also note, that for Windows client you can use this filter only via GPO. On server side you can use cli to define the filer, as far I know,..

But in the End, those retransmissions are no issue at all :-)

Hope this helps Cheers Henrik

I filtered the capture on tcp.stream eq 0 and it looks like the application is using some sort of telemetry request\response or event\acknowledge protocol and the .131 endpoint is very fussy about getting a timely response from the .33 endpoint as it sends a small packet (16 bytes payload) and then approx. 20ms later retransmits that packet and subsequently the .33 endpoint does respond very quickly with a TCP ACK.

I'm not sure why the .133 endpoint is retransmitting so quickly though, normally the TCP stack would wait a little longer for the TCP ACK before retransmitting. I suspect something in the application is causing this.