From owner-freebsd-net@FreeBSD.ORG Thu Jun 3 00:20:18 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 1F05516A4D0 for ; Thu, 3 Jun 2004 00:20:18 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5AD5C43D2D for ; Thu, 3 Jun 2004 00:20:17 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 34376 invoked from network); 3 Jun 2004 07:19:51 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 3 Jun 2004 07:19:51 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 3 Jun 2004 02:19:43 -0500 (CDT) From: Mike Silbersack To: Don Lewis In-Reply-To: <200406030427.i534RAdh003365@gw.catspoiler.org> Message-ID: <20040603021629.S70117@odysseus.silby.com> References: <200406030427.i534RAdh003365@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: dmitry@atlantis.dp.ua cc: freebsd-net@FreeBSD.org Subject: Re: net.inet.ip.portrange.randomized=1 hurts 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: Thu, 03 Jun 2004 07:20:18 -0000 On Wed, 2 Jun 2004, Don Lewis wrote: > Randomizing DNS query IDs without repeating any particular ID too > quickly is a similar problem. I contributed some code to for this to > BIND version 8 a number of years ago. See the nsid stuff in > /usr/src/contrib/bind/bin/named/ns_main.c. There are some comments > preceeding the code that explain the background and how it is supposed > to work. Something like this might be suitable for port number > allocation, though the potentially long time that a given port number > might be in use would complicate things. I just thought more about the issue at hand, and I think that changing the randomization algorithm is probably not worth the effort. Instead, we'll have to fix the server-side TIME_WAIT problem Dmitry is experiencing. The simple reason is that any other OS which uses randomized ephemeral ports will tickle the exact same port recycling problem, so reverting our client behavior isn't a long-term solution. I'm still too swamped to poke at the problem. Mike "Silby" Silbersack