Re: [PATCH 3/3] Revert Backoff [v3]: Calculate TCP's connection close threshold as a time value.

On Mon, Jun 4, 2012 at 12:18 PM, Ilpo Järvinen
[off-list ref] wrote:

On Mon, 4 Jun 2012, Damian Lukowski wrote:

quoted

please verify, I understood you correctly.

You have set TCP_RTO_MIN to a lower value, e.g. 0.002 seconds to improve
your internal low-latency traffic. Because of the improvement, R1
timeouts are triggered too fast for external high-RTT traffic. Is that
correct?
If so, may I suggest to set tcp_retries1 to a higher value? For
TCP_RTO_MIN == 0.002 and tcp_retries1 ==  10, R1 will be calculated to
approximately 4 seconds.

Is that ok?

I suppose what he meant is that you could have e.g., 60sec RTT and with
small enough retries the timeout calculation yields to some timeout
smaller than 60 secs, and therefore no retransmissions are made which is
certainly not a desirable property? ...This is valid issue even if no min
rto tweaking was done but can of course get much worse if min rto is
shorter.

The extreme case you described above won't happen because there is a
point check at the beginning to return false if inet_csk(sk)->icsk_retransmits
is zero. But that seems to be a hack because why is 0 so special, not 1, 2,...?

I agree with his proposed solution:

quoted

quoted

I think retransmits_timed_out() should check against both time
duration and retrans count (icsk_retransmits).

...that is, use both pseudo timeout check of the current code and the
previously used icsk_retransmits compare at the same time.

Yep, it's not an ideal solution, i.e., the problem the original patch
tried to address
may continue to exist if the gap between TCP_RTO_MIN used as an estimator
and the real RTO is large, but it at least addresses the problem we
have locally.

I will submit a patch for this asap.

Thanks,

Jerry

--
 i.