"clients-per-query" vs "max-clients-per-query"

[Evan Hunt]

On Sun, Jun 08, 2014 at 09:45:23AM -0400, Timothe Litt wrote:
> Consider a continuous stream of queries to a slow server.  For the sake
> of exposition, assume the incremental adjustment is 1 rather than 5.
> 
> Named drops the 11th query, but increases the limit.

It only increases the limit if one of the pending queries for that name
got an answer back.  If the authoritative server's not responding at all,
we just carry on dropping queries, but if *is* answering -- just not
quickly enough to keep up with demand -- then we adjust our queue
lengths. 

The code was written before my time, so I'm only guessing here, but I
suspect the idea was to adapt to the situation where you have a fast
local network and a slow upstream connection.  If we're getting queries
for popular names faster than we can resolve them, it may make sense to
buffer more queries.

> For the former, a global threshold makes some sense - an abusive burst
> of queries can be for multiple zones - or focused on one.
> But isn't this what response rate limiting is for?  Given RRL, does this
> still make sense?

RRL is response rate limiting -- it applies to output not input.

> For the latter, separating the measurement/threshold tuning from the
> decision to drop would seem to produce more sensible behavior than
> dropping every 5i-th packet.  And for it to make any sense at all, it
> must be adjusted per server, not globally...

As it happens I'm in the middle of a research project on this very
subject; future releases will probably have some additional per-server
throttling and holddown controls and more finely adjustable drop
policies.  Stay tuned.

> Or I'm missing something, in which case the documentation needs some
> more/different words :-(

If the above was helpful and you feel inspired to rephrase it into
text for the ARM, I'm always happy to take your patches. :)

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.