From owner-freebsd-arch Wed Jul 18 9:35:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 64ABF37B401 for ; Wed, 18 Jul 2001 09:35:53 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.138.210.Dial1.SanJose1.Level3.net [209.247.138.210]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id JAA12666; Wed, 18 Jul 2001 09:35:37 -0700 (PDT) Message-ID: <3B55BAFA.B507F39C@mindspring.com> Date: Wed, 18 Jul 2001 09:36:10 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: Peter Wemm , freebsd-arch@FreeBSD.ORG Subject: Re: TCP Initial Sequence Numbers: We need to talk References: <20010717224921.W3744-100000@achilles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Silbersack wrote: > > How about attempting to kill two birds with one stone and really solve the > > SYN flood problem at the same time as dealing with the ISS stuff. > > A SYN Cache would be good (and I was planning to work on such issues when > I get more time), but it's really unrelated to the issue at present. > > Netbsd's RFC1948 support isn't actually in use yet; it looks Jason Thorpe > added it, then didn't trust it enough to enable it yet. :) Ashutosh S. Rajekar, near the end of June on -hackers, suggested that a SYN-cache that held onto the cached object even after the SYN-SYNACK-ACK, until the first data down the pipe, might be a good idea. This is much more agressive... I'm not sure it's called for, but, for high contention, high latency links, I think I like the idea much more than the simple cache that will actually allocated the inpcb, tcpcb, and socket, after getting the final ACK of the handshake. If you are actually thinking of doing this, you might want to look at using the BSDI version of the SYN cache code, instead. Neither one implements Ashutosh's "aggressive Syn cache" idea, though... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message