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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists