Jonathan Stone writes:
> 
> 4. I can think of two possible applications for a proper rate-limit
>    (e.g,. leaky bucket) filter
>       * allowing bursts of ICMP queries at boot, caused by nameserver
>         probes
>      * allowing `short' bursts of ICMPs in response to traceroute,
>         when the router getting the TTL-exceeded packets is not under
>         a denial-of-service attack.
>      * allowing for bursts of syslog messages at the acutal time
>        of exception conditions, but also enforcing an N per M seconds,
>        long-term rate.

This should all be part of QoS under NetBSD.  Traffic shaping or other
rate limiting is needed in other areas along with various queuing 
methods.  I don't know if something like ALTQ would be applicable here
or not.
NetBSD needs general QoS type services integrated.  We need to be
able to rate limit flows, DoS, and provide queuing.  WFQ in the filesystem
would be excellent as well. :)

Perhaps a more general purpose "Event Per Quantum" needs to be developed
at this point so it can be utilized by more than just ICMP.

-Andrew
-- 
-----------------------------------------------------------------
Andrew Gillham                            | NetBSD ist Affengeil.
gillham@whirlpool.com                     | Nachts ist es kaelter
I speak for myself, not for my employer.  | als draussen.