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
