[ratelimits] Remarks regarding the Knot DNS 1.2.0 RRL implementation

[Vernon Schryver]

> From: =?UTF-8?Q?Marek_Vavru=C5=A1a?= <marek.vavrusa at nic.cz>

>  I used the default table size (prime near 1.5M)

> > I honestly do not understand why any RRL implementation does not use
> > some sort of chaining. It both saves memory and prevents failures.
>
> Depends, we now use 16B per bucket, so...

To handle 100K qps, you don't need more than about 100K counters,
timers, etc.  16 Bytes times 1.5M is more than even 160 bytes * 100K.
In other words, I'm confident that the BIND9 RRL code uses less memory
for a given target qps load, despite also keeping frills.  The cost
in the BIND9 RRL code is CPU cycles spent chasing chains.


>  if it is what our users want, then I'll probably implement it.

One cannot really delegate arcane implementation decisions to users
or managers, most of whom do not care that they could not write a hash
functions and misunderstand "collision" as "something that sounds bad."
You must signal the right answer to let them to "decide" obscure
questions, and so regardless of their illusions, you have really
decided.  Experienced technicians know this, which is why you keep
trying to conflate qname compression with RRL false positives/negatives.
(I also did it in that last sentence.)

As I've written elsewhere, although I feel strongly about it, I know
it is a minor difference, especially compared to control file syntax.

No one has mentioned differences in logging or statistics, but
they are doubtless large.  Most mixed installations could surmount
configuration format differences and would not notice any differences
due to hash collisions.  One of the reasons they would not notice
any differences due to hash collisions is that reconciling logs and
statistics counters would be hard.

That is part of the price of code diversity.


Vernon Schryver    vjs at rhyolite.com