Date: Wed, 28 May 2003 12:02:34 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Barney Wolff <barney@databus.com> Cc: freebsd-net@freebsd.org Subject: Re: [dab@BSDI.COM: Re: [e2e] TCP-SYN and delayed TCB allocation] Message-ID: <20030528115405.M39182@odysseus.silby.com> In-Reply-To: <20030528155914.GA4573@pit.databus.com> References: <20030528155914.GA4573@pit.databus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 May 2003, Barney Wolff wrote: > I found this message interesting. > Can someone point me to the rationale for putting all conns through > the syncache? > Thanks, > Barney The main rationale is simple: Code duplication. If we kept both the incomplete listen queue and the syn cache, any incoming syn-ack would have to search both of them. I agree that FreeBSD's syn cache could be better, jlemon and I talked about incorprorating some of Yahoo's patches to it, but we haven't had time yet. The main problem now is that we calculate syncookies for everything, and that we kick entries out of the syncache in FIFO order. What we should do is change things around so that we never kick out syncache entries due to incoming packets (although we could reduce their lifetime during attack), and only use syncookies for connections not resident in the syncache. That would increase our efficiency while under attack, although we're still in decent shape right now. I think the main difference in opinion is that we use the syncache to replace the incomplete listen queue, with syncookies as the backup plan. BSDI apparently still uses the incomplete listen queue as the main mechanism, with a syncache as backup. Hence, we're both going to be defensive about our implementations. If you want to arrange a syn-floodoff, I'd be interested in seeing the results. :) Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030528115405.M39182>