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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 Jun 2012 16:57:46 -0700
From:	Jerry Chu <hkchu@...gle.com>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Cc:	Damian Lukowski <damian@....rwth-aachen.de>,
	Netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: 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
<ilpo.jarvinen@...sinki.fi> wrote:
> On Mon, 4 Jun 2012, Damian Lukowski wrote:
>
>> 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:
>
>> > 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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html