From owner-freebsd-net@FreeBSD.ORG Wed Jan 21 00:50:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE22716A4CE for ; Wed, 21 Jan 2004 00:50:16 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 9B2DB43D4C for ; Wed, 21 Jan 2004 00:50:15 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 89347 invoked from network); 21 Jan 2004 08:50:14 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 21 Jan 2004 08:50:14 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 21 Jan 2004 02:50:12 -0600 (CST) From: Mike Silbersack To: richard@wendland.org.uk In-Reply-To: <200401200027.AAA09260@starburst.demon.co.uk> Message-ID: <20040121024817.I56100@odysseus.silby.com> References: <200401200027.AAA09260@starburst.demon.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Ken Faiczak cc: freebsd-net@freebsd.org Subject: Re: forged tsecr giving -ve numbers in rtt calculation causing retran X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2004 08:50:17 -0000 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