On 01/08/2018 12:37 PM, Tony Finch wrote:
Tom <tomtux...@gmail.com> wrote:
Mmmh...I can't verify the meaning of the "window"-value. In my flood-tests, it
makes no differences, if I set this value to 5 or 60 or even 3600.
You'll only notice the window if you pause your flood test - it's
basically the recovery time. (This is why the "stop limiting" log message
is misleading: RRL actually stops limiting after the window passes, but it
logs 60s later.)
This delayed log-entry seems now clear.
The relevant part of the ARM is:
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.
So, during your flood test, your client's token bucket will have its
minimym value, -1 * window * responses-per-second. When it stops, the
token bucket value will increase by `responses-per-second` each second, so
it will increase past zero after `window` seconds, and at that point RRL
will stop dropping responses.
This means, that with a "window 30;", I'll have to wait for about 30s
until the nameserver stops dropping requests (after I've stopped
flooding)....right? In my tests, this never matches.
If I set the "responses-per-second 5;" and the "window 30;", then begin
flooding (the responses are correctly dropped), then stop flooding, then
querying the nameserver from the same source for the same RR, I'll get
immediately the right answer.
Any explanations for this behavior?
Kind regards,
Tom
Tony.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
