On Wed, Jun 15, 2016 at 1:34 PM, Daniel Metz [off-list ref] wrote:

Yuchung Cheng | 2016-06-15 20:02:

quoted

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()