On Mon, Nov 3, 2014 at 4:35 PM, Marcelo Ricardo Leitner
[off-list ref] wrote:

So by sticking with the recovery for a bit longer will help disambiguate the
3 dupacks on high_seq, if they ever happen, and with that avoid re-entering
Fast Retransmit if initial (2) happen. It's at the cost of leaving the fast
retransmit an ack later but if (2) happens the impact would be much worse,
AFAICS.

Yes, that's my sense.

Cool, thanks Neal. If Yuchung is okay with it, I'll proceed with just
zeroing that tstamp as initially proposed.

Yes, that sounds good to me for a short-term fix for the "net" branch,
as long as it's:

+  if (!tcp_any_retrans_done(sk))
+    tp->retrans_stamp = 0;

Longer-term ("net-next"?) perhaps it makes sense to remove the hold
state and protect against this spurious FR situation at the time we
decide to enter Fast Recovery, which seems to be the model the RFC is
suggesting.

neal