0

I'm using TCP over a very lossy network system (almost 20% drop rate) but one with extremely low latency (<2ms). And the default TCP implementation on our Linux system is atrocious. Sometimes it waits 5-6 seconds before re-transmitting packets. On the other side, our TCP stack just retries every 20ms, and it's fine.

I can't find any way to manually incur a re-transmission, even with TCP_NODELAY and sending no data aggressively. Also, there do not appear to be per-socket configurations for this. As we only want to change the timing for specific sockets (the ones on this network).

Is there any kernel feature for either manually re-transmitting with TCP or aggressively set the timers such to allow many retries per second?

(I am aware this is a similar (but not the same)) issue as the person in this thread: Application control of TCP retransmission on Linux -- but I do not want to close the connection, like TCP_USER_TIMEOUT just make it keep retrying, a lot.

Charles Lohr
  • 695
  • 1
  • 8
  • 23
  • I don't think TCP is designed to work with 20% loss rate. You will need either a custom transport protocol, or have a reliable link layer. – Effie Jan 29 '22 at 12:13
  • TCP congestion control and loss recovery in particular are not designed to handle networks with frequent non-congestion-related packet losses. – Effie Jan 29 '22 at 12:19

1 Answers1

1

TCP_NODELAY is an entirely unrelated options - it disables Nagle's algorithm for consolidating packets - it is used on interactive connection such as ssh where it is desirable to have every single character in a separate packet (to get an immediate remote echo).

Normally, the TCP layer will continuously monitor the RTT (Round-Trip Time) for receiving an ACK and will readjust its timeout. This is called Karn's Algorithm.

AFAIK, There are no tunables in the Linux kernel when it comes to retransmissions because this is something that is specified by the RFCs and it is embedded in the protocol.

I suggest you read this introduction: https://www.catchpoint.com/blog/tcp-rtt and then to capture a packet dump containing those exceptionally long retransmissions and post them here.

Also, are you sure that the packet loss is the same in both directions? This can be an explanation.

mmomtchev
  • 2,497
  • 1
  • 8
  • 23
  • No, packet loss is unidirectional. One direction we can have hardware acks, the other direction is best-effort. We have a work-around now. We have a client running on one side, that connects to SSH, and another on the other computer, and we just use UDP in the middle to schlep the data across, with retries, etc. This seems to work flawlessly. It's unfortunate that the TCP stack is so limited. – Charles Lohr Feb 03 '22 at 19:40