From owner-freebsd-net Wed Dec 13 12: 9:48 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 12:09:47 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id E2A3E37B402 for ; Wed, 13 Dec 2000 12:09:46 -0800 (PST) Received: (qmail 13717 invoked by uid 1000); 13 Dec 2000 20:09:46 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Dec 2000 20:09:46 -0000 Date: Wed, 13 Dec 2000 14:09:46 -0600 (CST) From: Mike Silbersack To: "Richard A. Steenbergen" Cc: Bosko Milekic , freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Dec 2000, Richard A. Steenbergen wrote: > Is there some specific reason you need timestamp seperate? If you're > really up for that, why not just limit each ICMP type seperately? There's no real need for it to be separate, it just feels cleaner. I prefer seeing the two cases have separately reported values. (Have I missed any icmp types that a host could respond with? If so, please tell me so that I can add them.) > As for performance, this limiting occurs deeper in the stack then ipfw, > and w/dummynet you have the flexability to mask the ips so that each > interface or aliased ip could have a seperate rate limit as well. Hm, true. I was thinking of limiting the outgoing side, which would mean ipfw comes later in the string, but I suppose that if you limit on the incoming ipfw's sooner. > My thinking on the matter is that these limits should provide basic > protection out of the box, and site specific limits should be done with > dummynet. I personally agree with this patch because I think there should > be seperate limits at some fundimental level, such as tcp-closed tcp-open > udp(closed) icmp-response and icmp-error. How much further you want to > push it is debatable mainly just because of the hastle of too many > unnecessary tunables, not for any real performance or memory reasons. I wasn't planning to subdivide the reporting any more in future patches, so you shouldn't see any new tunables popping up for that reason. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message