Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Dec 2000 14:09:46 -0600 (CST)
From:      Mike Silbersack <silby@silby.com>
To:        "Richard A. Steenbergen" <ras@e-gerbil.net>
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.0012131358070.13447-100000@achilles.silby.com>
In-Reply-To: <Pine.BSF.4.21.0012131443470.816-100000@overlord.e-gerbil.net>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0012131358070.13447-100000>