netdev - Re: [MaybeSpam] Re: [PATCH 2.6.22-rc5] TCP: Make TCP_RTO

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: <20070628.065754.132846467.noboru.obata.ar@hitachi.com>
Date:	Thu, 28 Jun 2007 06:57:54 +0900 (JST)
From:	noboru.obata.ar@...achi.com
To:	kaber@...sh.net
Cc:	davem@...emloft.net, shemminger@...ux-foundation.org,
	netdev@...r.kernel.org, noboru.obata.ar@...achi.com
Subject: Re: [MaybeSpam] Re: [PATCH 2.6.22-rc5] TCP: Make TCP_RTO_MAX a
    variable

Patrick McHardy wrote:
> OBATA Noboru wrote:
> > From: OBATA Noboru <noboru.obata.ar@...achi.com>
> > 
> > Make TCP_RTO_MAX a variable, and allow a user to change it via a
> > new sysctl entry /proc/sys/net/ipv4/tcp_rto_max.  A user can
> > then guarantee TCP retransmission to be more controllable, say,
> > at least once per 10 seconds, by setting it to 10.  This is
> > quite helpful on failover-capable network devices, such as an
> > active-backup bonding device.  On such devices, it is desirable
> > that TCP retransmits a packet shortly after the failover, which
> > is what I would like to do with this patch.  Please see
> > Background and Problem below for rationale in detail.
> 
> 
> Would it make sense to do this per route?

Well, for a certain case, maybe yes.

For example,

(1) You have both a fast route (link) and a slow route,
(2) You want to use a short RTO for the fast route and not for
    the slow route, and
(3) Routes are static, as mentioned by Siim.

On such a case, only a global tcp_rto_max, which is set to a
very small value, may overload the slow link due to many
retransmission packets.  Then, as Stephen mentioned, people will
find it useful to have per route tcp_rto_max.

But let me give you some number.

The number of retramsmission packets in the first 60[s] on
tcp_rto_max = 10[s], starting from RTO = 0.2[s], are:
	10 with tcp_rto_max = 10[s], where
	8 with tcp_rto_max = 120[s] (original).

Only extra 2 packets per minute per socket should be acceptable
in most cases.

So if you choose a moderate tcp_rto_max, you may not necessarily
need per route tcp_rto_max.

Regards,

-- 
OBATA Noboru (noboru.obata.ar@...achi.com)

-
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