Hello @Eggi ,
Thanks for the .etl file - it was satisfying to see how clearly it shows "tail loss probe" behaviour.
In the .pcapng file that you made available, there were four retransmissions and one can measure the time from sending the last small segment to the retransmission of that data. For example:
15:17:21.239458 192.168.127.10.57117 > 192.168.127.200.50101: P 16129:16385(256) ack 1 win 64544 (DF)
15:17:21.270311 192.168.127.10.57117 > 192.168.127.200.50101: P 12353:16385(4032) ack 1 win 64544 (DF)
Here, the interval is 30.85 milliseconds and the subsequent intervals are 38, 61 and 106 milliseconds.
The default Tail Loss Probe (TLP) timeout is 2*SRTT (SRTT = smoothed round trip time); the .etl file shows how the SRTT develops during the transfer:
The .etl file also contains explicit events for TLP - they look like this:
The TLP mechanism "probes" with the next packet (rather than old (retransmitted)) data if it is available and allowed by the various "window" limitations (e.g. send window, congestion window). The .etl file shows how the congestion window develops over time:
It does not look as though the send/congestion windows are the problem and this is confirmed by the connection summary:
This basically says that the reasons for all the delays in sending data was lack of new data (the "R" before "Snd" in the last two lines is probably a typo in the ETW manifest).
It seems that your application is only sending a new 16 kibibyte "message" (block of data) when the previous block has been "flushed" (sent and acknowledged), so the only data available for a TLP is old data (hence the retransmissions).
The Windows side is behaving perfectly correctly and appropriately - it is the long delay before data is acknowledged that is causing the retransmissions.
Gary