response-rate-limiting - "window" explained?

[Tom]

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. The only value which affects the behavior is "slip" and 
"responses-per-second".
When I fast-querying (100r/s) the nameserver with the following 
configuration:.....
         rate-limit {
                 responses-per-second 5;
                 slip 0;
                 window 5;
                 log-only no;
         };


....the nameserver answers always every five seconds for five requests:
Mon Jan  8 07:36:05 CET 2018       querying example.org
Mon Jan  8 07:36:05 CET 2018       querying example.org
Mon Jan  8 07:36:05 CET 2018       querying example.org
Mon Jan  8 07:36:05 CET 2018       querying example.org
Mon Jan  8 07:36:05 CET 2018       querying example.org
Mon Jan  8 07:36:10 CET 2018       querying example.org
Mon Jan  8 07:36:10 CET 2018       querying example.org
Mon Jan  8 07:36:10 CET 2018       querying example.org
Mon Jan  8 07:36:10 CET 2018       querying example.org
Mon Jan  8 07:36:10 CET 2018       querying example.org
Mon Jan  8 07:36:15 CET 2018       querying example.org
Mon Jan  8 07:36:15 CET 2018       querying example.org
Mon Jan  8 07:36:15 CET 2018       querying example.org
Mon Jan  8 07:36:15 CET 2018       querying example.org
Mon Jan  8 07:36:15 CET 2018       querying example.org

And here it makes no differences, if I set the "window"-value to 5 or 60 
or 3600.


Any hints / explanation for the behavior of the "window"-value?


Many thanks.
Tom


On 01/05/2018 07:27 PM, Tony Finch wrote:
> Tom <tomtux007 at gmail.com> wrote:
> 
>> Could someone explain the problem here? Why do I never have to wait longer
>> than about 5s until I'm able to query the nameserver from the unique client
>> with the same query again?
> 
> The 60s is the delay after a client has stopped making queries when the
> information about that client can be forgotten. RRL logs "stop limiting"
> at that point which is a bit misleading.
> 
> Tony.
>