> On June 15, 2016 at 10:38 PM Eric Dumazet <eduma...@google.com> wrote: > > I guess the problem is that some folks use smaller rto than > RTAX_RTO_MIN , look at tcp_rto_min()
Due to the nature of the Linux calculation, this is probably more of a reason to use the RFC 6298 calculation. When a smaller MinRTO as 200ms is used, the Linux “advantage” to account for Delayed ACKs up to 200ms is decreased. Assuming a MinRTO of 0ms, the Linux ability and the RFC ability to account for sudden Delayed ACKs is pretty equal: zero. To illustrate this: RTT: 50ms, RTTVAR: 0ms, MinRTO: 50ms, Delayed ACKs: 200ms. Before any ACK is delayed: Linux RTO ~ 100+ms (tested) RFC 6298 RTO ~ 50+ms (tested) RTT of first delayed ACK if it is not shortened due to another data packet: ~250ms This is not tied to the RTT: RTT 1000ms, RTTVAR: 0ms, MinRTO: 50ms, Delayed ACKs: 200ms Before any ACK is delayed: Linux RTO ~ 1050+ms (tested) RFC 6298 RTO ~ 1000+ms (tested) RTT of first delayed ACK if it is not shortened due to another data packet: ~1200ms A RFC 6298 problem we run in so far was with extremely steady RTTs and sender limited data. A Spurious Retransmission occurred from time to time in this case. Hagen
