Date: Tue, 20 Apr 2004 03:34:44 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: src-committers@FreeBSD.org Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_subr.c tcp_var.h Message-ID: <20040420032850.H20848@odysseus.silby.com> In-Reply-To: <200404200633.i3K6XdXn067858@repoman.freebsd.org> References: <200404200633.i3K6XdXn067858@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040420032850.H20848>