Fix spurious retransmit recovery on low latency networks

[kmacy]

Summary

TCP's smoothed RTT (SRTT) can be much larger than an actual observed RTT. This can be either because of hz restricting the calculable RTT to 10ms in VMs or 1ms using the default 1000hz or simply because SRTT recently incorporated a larger value.

If an ACK arrives before the calculated badrxtwin (now + SRTT):
tp->t_badrxtwin = ticks + (tp->t_srtt >> (TCP_RTT_SHIFT + 1));

We'll erroneously reset snd_una to snd_max. If multiple segments were dropped and this happens repeatedly the transmit rate will be limited to 1MSS per RTO until we've retransmitted all drops.

[kmacy]

simplify badrxtwin assignment

[kmacy]

Add comment to tcp_timer.c as requested by hiren@

[hiren]

Thanks for this fix. Nice catch.

Please also mention in the commit log that now we are tracking this functionality separately for timestamps and non-timestamps case.

sys/netinet/tcp_timer.c

717

Please add a comment here that this is handling non-ts case and ts case is handled in tcp_output.c
It may seem obvious but comments would help. :-)

[kmacy]

add missed check

[kbowling]

@kmacy is this still relevant?

[kmacy]

@rstone have you committed an equivalent fix already?

[rstone]

@kmacy I have not. We probably have an equivalent fix committed locally @ $WORK but it might be tied too closely to the high-precision timestamp work to easily extract.