[ratelimits] Per second response limits and window size?

[Vernon Schryver]

> From: "MURTARI, JOHN" <jm5903 at att.com>

> ... We have one system (client) on another network that is simply
> using dnsperf to repeatedly send the same query at a rate of
> 100/second for a duration of 1 minute.

>  rate-limit {  
>     responses-per-second 50;
>     log-only no; slip 0; qps-scale 25000; window 10; ipv4-prefix-length 24;
>   };

> What we get reported from dnsperf is 6000 queries sent and only
> 60 replies?   Reviewing the tcpdump output confirms these figures,
> 60 replies are immediately sent in the first two seconds, and then
> nothing.  

Please reread the draft RRL ARM text found by following the link labeled
"Draft text for BIND9 Administrators Reference Manual (ARM) ..." on
http://www.redbarn.org/dns/ratelimits:

   Response rate limiting uses a "credit" or "token bucket" scheme.
   Each combination of identical response and client has a conceptual
   account that earns a specified number of credits every second.
   A prospective response debits its account by one. Responses are
   dropped or truncated while the account is negative. Responses
   are tracked within a rolling window of time which defaults to
   15 seconds, but can be configured with the window option to any
   value from 1 to 3600 seconds (1 hour). The account cannot become
   more positive than the per-second limit or more negative than
   window times the per-second limit. When the specified number of
   credits for a class of responses is set to 0, those responses
   are not rate limited.

I do not understand you read that as saying that the "window" does
more than limit the minimum (most negative) value of the counter.

If dnsperf started 900 milliseconds after the start of second and
so sent 10 queries in the first second, then the RRL credit would
start at 50 and be reduced to 40 those first 10 queries are answered.
At the start of the 2nd or first full second, the counter would be
increased by the responses-per-second value but limited to that
value and so set to 50.  The first 50 queries in that second would
be answered as the counter is decreased to 0.  The other 50 queries
would drive the counter to -50.

At the start of the third second, the counter would be increased by 50
to 0.  The first query in the third second would set the counter to -1
and so not be answered.  At the end of the third second, the counter would
be -100.

At the start of the fourth second, the counter would be increased to -50,
and then driven to -150 as those 100 queries are not answered.  

By the 6th second, the counter will be at its lower limit of -500
or -(responses-per-second*window).  This lower limit is the only
explicit effect of "window."

For about 10 seconds after dnsperf stops sending, the counter will
increase from about -500 to -450, -400, -350, and so forth until it
reaches its maximum of 50.  These 10 seconds of gradually increasing
but still negative and so blocking counter are why the value is called
"window".   I say "about" because exactly what happens depends on how
many queries dnsperf sends in the last second.


Vernon Schryver    vjs at rhyolite.com