Date: Wed, 13 Dec 2000 15:25:58 -0500 (EST) From: "Richard A. Steenbergen" <ras@e-gerbil.net> To: Mike Silbersack <silby@silby.com> Cc: Bosko Milekic <bmilekic@technokratis.com>, freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) Message-ID: <Pine.BSF.4.21.0012131512230.816-100000@overlord.e-gerbil.net> In-Reply-To: <Pine.BSF.4.21.0012131358070.13447-100000@achilles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Dec 2000, Mike Silbersack wrote: > 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.) Assuming the box is not acting as a router in any fashion... It doesn't matter, it really doesn't, I'm just note sure timestamp is really worth the hastle instead of just calling it icmp request... The advantage of seperate limits is to keep one service working when another is being limited. Since its a dirt simple operation to pick which limit you're hitting, and there are no queues involved just counters, it might be just as easy to go into the rate limiting function as icmp limit, and have it maintain seperate limits for every type, if you really wanted... > > 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. Historically bandlim has been the process of stopping the processing at input of things which would result in output... Do you want to (or need to) extend this? > 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. Same question as above, is this to be built in Denail of Service prevention, or is this limiting of packets which could potentially generate excessive processing or replies? Might as well do it right instead of kludging this up any more... :P -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0012131512230.816-100000>