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 22:34:00 +0200
From:	Daniel Metz <dmetz@...um.de>
To:	Yuchung Cheng <ycheng@...gle.com>,
	Hagen Paul Pfeifer <hagen@...u.net>
Cc:	netdev <netdev@...r.kernel.org>,
	Daniel Metz <daniel.metz@...de-schwarz.com>,
	Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next v2] tcp: use RFC6298 compliant TCP RTO
 calculation

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.

Daniel