From: Stephen Hemminger <stephen.hemminger@vyatta•com>
To: Stephane Chazelas <Stephane_Chazelas@yahoo•fr>
Cc: Stephen Hemminger <shemminger@vyatta•com>,
David Miller <davem@davemloft•net>,
netdev@vger•kernel.org
Subject: Re: rtt metric only for incoming connections?
Date: Tue, 27 May 2008 11:43:11 -0700 [thread overview]
Message-ID: <20080527114311.2734402b@speedy> (raw)
In-Reply-To: <20080522103610.GB5354@sc.homeunix.net>
On Thu, 22 May 2008 11:36:10 +0100
Stephane Chazelas <Stephane_Chazelas@yahoo•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.
next prev parent reply other threads:[~2008-05-27 18:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-21 16:38 [iproute2] get_hz() with CONFIG_HIGH_RES_TIMERS Stephane Chazelas
2008-05-21 16:56 ` Patrick McHardy
2008-05-21 17:40 ` [PATCH] net: neighbour table ABI problem Stephen Hemminger
2008-05-21 20:35 ` David Miller
2008-05-22 0:20 ` Thomas Graf
2008-06-03 23:03 ` David Miller
2008-05-21 17:10 ` [iproute2] get_hz() with CONFIG_HIGH_RES_TIMERS Stephen Hemminger
2008-05-21 18:43 ` route metrics in jiffies?? Stephen Hemminger
2008-05-21 20:31 ` David Miller
2008-05-22 10:36 ` rtt metric only for incoming connections? Stephane Chazelas
2008-05-27 18:43 ` Stephen Hemminger [this message]
2008-05-27 18:53 ` Rick Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080527114311.2734402b@speedy \
--to=stephen.hemminger@vyatta$(echo .)com \
--cc=Stephane_Chazelas@yahoo$(echo .)fr \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shemminger@vyatta$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox