From owner-cvs-src@FreeBSD.ORG Mon Apr 19 23:41:50 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A498716A4D0 for ; Mon, 19 Apr 2004 23:41:50 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 0D4C343D2F for ; Mon, 19 Apr 2004 23:41:50 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 4482 invoked from network); 20 Apr 2004 06:41:48 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 20 Apr 2004 06:41:48 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 20 Apr 2004 03:34:44 -0500 (CDT) From: Mike Silbersack To: src-committers@FreeBSD.org In-Reply-To: <200404200633.i3K6XdXn067858@repoman.freebsd.org> Message-ID: <20040420032850.H20848@odysseus.silby.com> References: <200404200633.i3K6XdXn067858@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_subr.c tcp_var.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 06:41:50 -0000 On Mon, 19 Apr 2004, Mike Silbersack wrote: > Enhance our RFC1948 implementation to perform better in some pathlogical > TIME_WAIT recycling cases I was able to generate with http testing tools. > > Except in such contrived benchmarking situations, this problem should never > come up in normal usage... until networks get faster. I think that we may have to break away from standard RFC handling and change the TIME_WAIT code in tcp_input so that it will accept any SYN packet coming in without regard to the sequence number, forcing the TIME_WAIT socket to be recycled. The problem is that right now we're using an increment rate of 1MB per second. This means that if a connection on a certain port is established on a gigabit network, more than 1MB/second is sent, the connection is closed, and then a new connection is attempted with the same port pair, it will fail because the SYN's sequence number will be less than the sequence number the previous connection ended with. We could somewhat address this by increasing the 1MB/second rate to something greater, but that would increase the rate of serial number wraparound, which probably isn't a good thing. Also, with a 32-bit sequence space, we just can't increase the rate so that it's fast enough to keep up with 1Gb/sec or 10Gb/second networks. So, I may tackle this at some point in the future, after I survey the other OSes and see how they're handling it. Mike "Silby" Silbersack