netdev - Re: TCP NewReno and single retransmit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADVnQykePToQ-MatwFV=o7iYw_1T7L_jg_3NtaXRueyMA=GAuw@mail.gmail.com>
Date:	Mon, 3 Nov 2014 18:17:21 -0500
From:	Neal Cardwell <ncardwell@...gle.com>
To:	Marcelo Ricardo Leitner <mleitner@...hat.com>
Cc:	Yuchung Cheng <ycheng@...gle.com>, netdev <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>
Subject: Re: TCP NewReno and single retransmit

On Mon, Nov 3, 2014 at 4:35 PM, Marcelo Ricardo Leitner
<mleitner@...hat.com> 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html