netdev - Re: [PATCH 2.6.22] 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]

Date:	Fri, 13 Jul 2007 07:29:45 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Rick Jones <rick.jones2@...com>
cc:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	noboru.obata.ar@...achi.com, David Miller <davem@...emloft.net>,
	yoshfuji@...ux-ipv6.org, Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)

On Thu, 12 Jul 2007, Rick Jones wrote:

> > One question is why the RTO gets so large that it limits failover?
> > 
> > If Linux TCP is working correctly,  RTO should be srtt + 2*rttvar
> > 
> > So either there is a huge srtt or variance, or something is going
> > wrong with RTT estimation.  Given some reasonable maximums of
> > Srtt = 500ms and rttvar = 250ms, that would cause RTO to be 1second.
> 
> I suspect that what is happening here is that a link goes down in a trunk
> somewhere for some number of seconds, resulting in a given TCP segment being
> retransmitted several times, with the doubling of the RTO each time.

But that's a back-off for the retransmissions, the doubling is 
temporary... Once you return to normal conditions, the accumulated backoff 
multiplier will be immediately cut back to normal. So you should then be 
back to 1 second (like in the example or whatever) again...

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