From owner-cvs-all Thu Dec 20 13:23:10 2001 Delivered-To: cvs-all@freebsd.org Received: from prism.flugsvamp.com (66-188-92-95.mad.wi.charter.com [66.188.92.95]) by hub.freebsd.org (Postfix) with ESMTP id 8CB1C37B417; Thu, 20 Dec 2001 13:22:58 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id fBKLMhT38208; Thu, 20 Dec 2001 15:22:43 -0600 (CST) (envelope-from jlemon) Date: Thu, 20 Dec 2001 15:22:43 -0600 From: Jonathan Lemon To: Mike Silbersack Cc: Jonathan Lemon , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c Message-ID: <20011220152243.H26326@prism.flugsvamp.com> References: <20011220143101.E26326@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 20, 2001 at 03:52:10PM -0500, Mike Silbersack wrote: > > On Thu, 20 Dec 2001, Jonathan Lemon wrote: > > > On Thu, Dec 20, 2001 at 02:28:42AM -0500, Mike Silbersack wrote: > > > > > > Hm, I have a question about this change: Isn't using md5 for every > > > outgoing packet going to eat a lot of cpu time? > > > > Not every outgoing packet, every outgoing SYN,ACK. And it is no more > > heavyweight than the existing tcp_new_isn(), which uses MD5 to generate > > the ISN for initial outgoing SYNs. > > MD5 is only used for outgoing syn-acks if strict rfc1948 mode is enabled > (which it is not by default); normally, arc4random is used. I think you missed the part that said "initial outgoing SYNs". E.g.: where we are the ones initially establishing the connection. > > > I think it might be a > > > more reasonable heuristic to change to md5 generation only when the syn > > > cache is more than half full and use arc4random at other times; this would > > > use less cpu in the common case, but provide the cookie support when it is > > > needed most. > > > > Hmm, this will break the syncookie logic; since you don't know ahead > > of time which entries are going to got dropped. > > I'm rusty on the syncache implementation, so bear with this if it's wrong: > If you're involved in being synflooded, the cache is going to be mostly > full. On the other hand, if you're not being flooded, the cache will > generally be mostly empty. Also, a flood is probably going to go on for a > while. Hence, if the table's above a certain percent full, you could > assume that you're should make cookies, because they'll be needed. > Otherwise, just use arc4random(), and accept that a few connections will > get dropped right when a flood starts, but that you'll be ok after that. Not quite; there is both a table and a bucket limit. Entries can be overflowed from either one of these. It would be possible to add various watermarks and change behavior when the watermarks are hit. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message