In message <200007091851.OAA01198@multics.mit.edu>John Hawkinson writes
>[ dropped source-changes ]
>
>In message <5006.963162552@coconut.itojun.org>, itojun@iijlab.net writes:
>
>>>being more generic (configurable period).
>>
>>	i just do not feel like adding more complexity into it.  do you have
>>	a plan for real use of "N events in M second"?  if that can be
>>	covered by "N events in 1 second", I'd say i like simpler one.

Piggybacking, and in no particular order:

1. "pps" is not a good name choice, we already have the
    pulse-per-second interface using pps* and PPS ioctls.
    something unique would be preferable.

2. I agree with jhawk: the current state is symptomatic of a design flaw.   
   i think we should fix it.

3.   If we are going to do rate limiting, let's do it properly:
     define a leaky-bucket filter, with maximum-depth
     and fill-rate parameters, scaled by hz; and perhaps with a
     scale-factor argument.

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.

I thought that's what was originally proposed, not the coarse one-knob
filters we have now.  Or is -current different from the release
branch?

>Besides, if we really did make the period configurable, we'd
>have to totally throw out the ppsratecheck() name. ;-)

Along with throwing out a one-parameter ppsratelimit(), if we do it
properly :)