tcp: always set retrans_stamp on recovery
Previously TCP socket's retrans_stamp is not set if the retransmission has failed to send. As a result if a socket is experiencing local issues to retransmit packets, determining when to abort a socket is complicated w/o knowning the starting time of the recovery since retrans_stamp may remain zero. This complication causes sub-optimal behavior that TCP may use the latest, instead of the first, retransmission time to compute the elapsed time of a stalling connection due to local issues. Then TCP may disrecard TCP retries settings and keep retrying until it finally succeed: not a good idea when the local host is already strained. The simple fix is to always timestamp the start of a recovery. It's worth noting that retrans_stamp is also used to compare echo timestamp values to detect spurious recovery. This patch does not break that because retrans_stamp is still later than when the original packet was sent. Change-Id: I8d13ee5aee5ba84d3c42fb34fbb46da942a4b7d7 Signed-off-by:Yuchung Cheng <ycheng@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Neal Cardwell <ncardwell@google.com> Reviewed-by:
Soheil Hassas Yeganeh <soheil@google.com> Git-Commit: 7ae189759cc48cf8b54beebff566e9fd2d4e7d7c Git-repo: https://android.googlesource.com/kernel/common/ Signed-off-by:
Kaustubh Pandey <kapandey@codeaurora.org>
Loading
Please register or sign in to comment