netdev - rtt metric only for incoming connections?

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]

Message-ID: <20080522103610.GB5354@sc.homeunix.net>
Date:	Thu, 22 May 2008 11:36:10 +0100
From:	Stephane Chazelas <Stephane_Chazelas@...oo.fr>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: rtt metric only for incoming connections?

On Wed, May 21, 2008 at 11:43:54AM -0700, Stephen Hemminger wrote:
[...]
> The problem is that these values are now hardcoded into people's systems
> so anyone using the 'ip route' options: rttvar, rtomin, or rtt are broken.
> They might be lucky now (but I doubt it).
[...]

Hi Stephen, all

a slightly related question:

it seems that the "rtt" parameter provided in "ip route ... rtt
<value>" is not taken into account for the retransmission of
SYNs while it is for the retransmissions of SYN+ACKs, why would
that be (2.6.24.2)?

Also, it seems we can't lower the initial RTO below the RFC 1122
default of 3 seconds. 3 seconds may be appropriate for a host
for which we don't know how many hops, links, satellites are
needed to reach it, but what about local/corporate networks
where it's possible to administratively know the rtt so that it
can be hardcoded in the routing table.

For instance, on the office wireless network, I know the average
rtt is below the ms. Some SYNs may be lost, but they can't be
delayed more than a few hundred ms. So, I may want to specify in
the route to that network, the initial and maximum rto, so that
a down host can be detected in less than a second.

The delay before the first retransmission is 3 seconds at the
moment. That value is often more than what some applications are
ready to wait for (applications that are meant to be run locally
for instance). So, it's a shame, because the application will
timeout on the connect even before the first retransmission, so
the SYN retransmission mechanism is useless in that case.

Or is it because there's a risk of congesting the internet if
people misuse that? Note that applications can always reattempt
a connect to work around that (for SYNs to be sent more often).

It would be nice if what the "rtt" exactly is could be
clarified. For instance, if I understand correctly, by default,
the initial rtt is 0 and the rttvar 3s, which results in a rto
of 3s. That "rtt" is the smoothed rtt, right? (I think the
"route" man page from net-tools is incorrect about that, BTW.),
but then when setting those variables per route, it's the RTT
that can't be made lower than 3s, while rttvar can be as low as
rto_min (200ms by default). It's all very confusing (well, I'm
very confused ;).

regards,
Stéphane
--
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