netdev - Re: [PATCH net-next v2] tcp: use RFC6298 compliant TCP RTO calculation

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]

Date:	Wed, 15 Jun 2016 14:07:21 -0700
From:	Yuchung Cheng <ycheng@...gle.com>
To:	Eric Dumazet <edumazet@...gle.com>
Cc:	Daniel Metz <dmetz@...um.de>, Hagen Paul Pfeifer <hagen@...u.net>,
	netdev <netdev@...r.kernel.org>,
	Daniel Metz <daniel.metz@...de-schwarz.com>
Subject: Re: [PATCH net-next v2] tcp: use RFC6298 compliant TCP RTO calculation

On Wed, Jun 15, 2016 at 1:38 PM, Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Wed, Jun 15, 2016 at 1:34 PM, Daniel Metz <dmetz@...um.de> wrote:
> > Yuchung Cheng | 2016-06-15 20:02:
> >> Let me explain in a different way:
> >>
> >> * RFC6298 applies a lower bound of 1 second to RTO (section 2.4)
> >>
> >> * Linux currently applies a lower bound of 200ms (min_rto) to
> >> K*RTTVAR, but /not/ RTO itself.
> >>
> >> * This patch applies the lower bound of 200ms to RTO, similar to RFC6298
> >>
> >>
> >> Let's say the SRTT is 100ms and RTT variations is 10ms. The variation
> >> is low because we've been sending large chunks, and RTT is fairly
> >> stable, and we sample on every ACK. The RTOs produced are
> >>
> >> RFC6298: RTO=1s
> >> Linux: RTO=300ms
> >> This patch: RTO=200ms
> >>
> >> Then we send 1 packet out. The receiver delays the ACK up to 200ms.
> >> The actual RTT can be longer because other network components further
> >> delay the data or the ACK. This patch would surely fire the RTO
> >> spuriously.
> >>
> >> so we can either implement RFC6298 faithfully, or apply the
> >> lower-bound as-is, or something in between. But the current patch
> >> as-is is more aggressive. Did I miss something?
> >
> > Thank you for the clarification. The fundamental thought of this patch was
> > to decrease Linux RTO overestimation. This also involved not clinging to the
> > RFC 6298 MinRTO of 1 second ((2.4) "[...] at the same time acknowledging
> > that at some future point, research may show that a smaller minimum RTO is
> > acceptable or superior."). A more aggressive RTO will of course increase the
> > amount of Spurious Retransmission. The question is, if the benefit is higher
> > than the sacrifice. The tests we conducted did not show significant negative
> > impact so far. However, for sender-limited TCP flows the results were
> > promising.
> >
>
> I guess the problem is that some folks use smaller rto than
> RTAX_RTO_MIN , look at tcp_rto_min()

Also many other stacks (e.g., Windows until very recently) do not have
40ms delayed ACKs like Linux. One thing we at least know is that the
current 200ms lower-bound on RTTVAR works for a long time. That's why
I propose to do so. In other words, change the RTT variation
averaging, but not the lower-bound.

Will try to get the experiment going to test different min_rto values
so we have more data.