On Tue, Nov 4, 2014 at 7:17 AM, Neal Cardwell [off-list ref] wrote:

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

quoted

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.

quoted

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.

Thanks for checking. So my suggested fix of removing the hold state is
the "less careful variant" that RFC does not recommend. I would rather
have the proposed 2-liner fix than implementing the section 6
heuristics to detect spurious retransmit. It's not worth the effort.
Everyone should use SACK.

neal