response-rate-limiting - "window" explained?

[Tom]

On 01/08/2018 12:37 PM, Tony Finch wrote:
> Tom <tomtux007 at 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.
>