Date: Wed, 21 Jan 2004 02:50:12 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: richard@wendland.org.uk Cc: freebsd-net@freebsd.org Subject: Re: forged tsecr giving -ve numbers in rtt calculation causing retran Message-ID: <20040121024817.I56100@odysseus.silby.com> In-Reply-To: <200401200027.AAA09260@starburst.demon.co.uk> References: <200401200027.AAA09260@starburst.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Jan 2004, Richard Wendland wrote: > This does suggest Ken is seeing TSecr messed up in some other way than > simple zeroing. Or working from an old codebase... we'll have to wait for him to respond to find out. KEN! KEN! WHERE ARE YOOOOOO? > I'd expect this to be a pretty rare event, and perhaps my suggestion > that the 64 sec TCPTV_REXMTMAX limit be implemented correctly is a > good enough solution on its own for a rare event. It should certainly > avoid the insane -450000000 tp->t_rxtcur Ken has seen. It's simple to > implement, does what was probably originally intended, and also protects > from bizarre problems with non-timestamp option SRTT calculation. > > Full validation of TSecr would be nice, but perhaps excessive for > something that should not happen. A 64 second RTO may discourage such > strangeness :) > > Richard I think that just ensuring proper capping of the timeout is good enough, the other timestamp issue I was referring to is how it (incorrectly) scales with hz. I think I'll take a look at both of these problems once I catch up on other patches I have in the pipeline. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040121024817.I56100>