netdev - Re: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20080527114311.2734402b@speedy>
Date:	Tue, 27 May 2008 11:43:11 -0700
From:	Stephen Hemminger <stephen.hemminger@...tta.com>
To:	Stephane Chazelas <Stephane_Chazelas@...oo.fr>
Cc:	Stephen Hemminger <shemminger@...tta.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: rtt metric only for incoming connections?

On Thu, 22 May 2008 11:36:10 +0100
Stephane Chazelas <Stephane_Chazelas@...oo.fr> wrote:

> 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.

Violating RFC's is not really that useful. If you have a network
dropping SYN packets regularly than there are worse problems.

> 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.

Relying on TCP to overcome wireless network problems is not
a good idea. 

> 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).

The problem is that distributions can't even get the settings right now.
It would be too easy for some distribution to ship with a default small
value.

> 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

RTT is used as a starting point for the smoothed round trip time.
As soon as the first ack comes back the value starts to change.
--
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