tcp: revert rxtshift too on a spurious timeout (RTO)

[rscheff]

Summary

When the tcp stack detects that a retransmission timeout was
spurious, many state variables are reverted back to their
previous values. However, the counter of how many subsequent
retransmission timeouts has been missed.

This can lead to an incorrect calculation of the congestion
window during Limited Transmit, as it is not recomputed
but only extended - possibly allowing more than one segment
to be transmitted for each limited transmit iteration.

Clearing the counter tracking the number of consecutive RTOs
will ensure that the calculation of the congestion window
during limited transmit is correct.

PR: 282605
MFC after: 3 days

[tuexen]

Wouldn't be the RTO after an erroneous RTO be computer incorrectly? Let me write a test for that...

[rscheff]

Well, if the RTO was indeed spurious, then the subsequent RTO timeout should be the base RTO timeout (again). So, only a false detection of a spurious timeout would (incorrectly) set the cadence to a slightly faster retransmission schedule in subsequent rounds... But if the RTO was spurious, so by definition shouldn't have been triggered anyway, I don't believe this causes a problematic behavior.

[tuexen]

In D48652#1109741, @rscheff wrote:

Well, if the RTO was indeed spurious, then the subsequent RTO timeout should be the base RTO timeout (again). So, only a false detection of a spurious timeout would (incorrectly) set the cadence to a slightly faster retransmission schedule in subsequent rounds... But if the RTO was spurious, so by definition shouldn't have been triggered anyway, I don't believe this causes a problematic behavior.

I am just saying: After a spurious RTO, the next RTO should be the same, not doubled. This can easily be tested. Such a test would identify the problem your fix addresses... Much more directly than testing limited transmit...