From owner-svn-src-head@FreeBSD.ORG Mon Apr 20 10:30:01 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CE77106566B; Mon, 20 Apr 2009 10:30:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 04E398FC14; Mon, 20 Apr 2009 10:30:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B05A346B0C; Mon, 20 Apr 2009 06:30:00 -0400 (EDT) Date: Mon, 20 Apr 2009 11:30:00 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Marko Zec In-Reply-To: <200904200844.12344.zec@freebsd.org> Message-ID: References: <200904190444.n3J4i5wF098362@svn.freebsd.org> <200904192221.55744.zec@freebsd.org> <3c1674c90904191405v56298134g286ea31ee4680769@mail.gmail.com> <200904200844.12344.zec@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Andre Oppermann , Kip Macy Subject: Re: svn commit: r191259 - head/sys/netinet X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 10:30:01 -0000 On Mon, 20 Apr 2009, Marko Zec wrote: >>> ... which makes a flow cache a perfect DoS target in any environment, be >>> it a DFZ or enterprise router or an end host or whatever. >> >> Uhm, assuming that you don't put a limit on the number of flows allocated - >> which I do. When you hit the zone limit for flows you simply stop caching >> new flows. > > ... which means you fall back to the ordinary routing lookups, but only > after you have wasted cycles to compute a hash and found out that it doesn't > match anything in your cache -> in this case I would expect only a > degradation in performance, not an improvement. The most recent example I'm aware of in our tree along those lines was from the 4.x time range, I believe. My memory is a bit hazy, but it goes something like this: in an initial analysis, we believed that the pain associated with a synflood was from connection state and hash lookups of that state. Actually, it turned out that much of it was from the creation of cloned routes for every remote IP address from which we received a SYN, as we would clone the route and cache it very early. Features like the syncache and syncookies were very important for mitigating SYN flood overhead, but in part because avoiding allocating routing-related state was actually just as, if not more, important as the "ordinary" connection state. Many of the concerns brought up in the discussion so far are reasons that I asked Kip to do the following with the flowcache: (1) Make this a kernel option (2) Disable it by default I would also agree with the view that if/when our routing table is more up-to-snuff, we might well want to lose the flowcache again, as arguably a revised routing table implementation, (combined with connection-oriented route/llentry caching) should not require or benefit from a flowcache. However, there's quite a bit of work required to get us there. Happily Kip already has a patch for route/llentry caching, but the historic opacity of the routing code is still hurting us in seeing optimization of the base routing table. Robert N M Watson Computer Laboratory University of Cambridge