On Wed, Jun 15, 2016 at 10:41 AM, Hagen Paul Pfeifer [off-list ref] wrote:

* Yuchung Cheng | 2016-06-14 14:33:18 [-0700]:

quoted

quoted

+               tp->rttvar_us = tp->mdev_us;

AFAICT we can update rttvar_us directly and don't need mdev_us anymore?

Yes, v3 will remove mdev_us.

quoted

This is more aggressive than  RFC6298 that RTO <- SRTT + max (G,
K*RTTVAR) where G = MIN_RTO = 200ms

based on our discussion, in the spirit of keeping RTO more
conservative, I recommend we implement RFC formula. Acks being delayed
over 200ms is not uncommon (unfortunately due to bloat or other
issues).

Also I think we should change __tcp_set_rto so that the formula
applies to backoffs or ICMP timeouts calculations too.

We are a unsure what you mean Yuchung. We believe this patch not to be more
aggressive than RFC 6298. In fact, we believe it to be RFC 6298 compliant, as
in RFC 6298, G is the clock granularity and we don’t see where it deviates
from the RFC. However, it is more aggressive than “RTO <- SRTT + max (G,
K*RTTVAR) where G = MIN_RTO = 200ms”. Which formula do you want to implement?

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?

Hagen