[ratelimits] Remarks regarding the Knot DNS 1.2.0 RRL implementation

Marek Vavruša marek.vavrusa at nic.cz
Wed Mar 6 22:30:30 UTC 2013


On 6 March 2013 21:06, Vernon Schryver <vjs at rhyolite.com> wrote:
>> 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.

I'd like more p/s, 100K was just the model case from your scenario.

>
>>  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.)

I am delegating the decision on "do you want us to behave like BIND9
RRL?" no arcane there.
Also, I am not trying to implicate anything, I just stated the fact
and that's it.
I will reiterate that I consider hashed qname in a bucket more than enough.

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

Agreed.

> 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.

Just for the curiosity, we don't print any statistics right now BUT we
had a request
to implement statistics in the exact format like BIND does.
I would format it differently, but I also see why is this request a
good idea and probably
will implement it that way. Because this is something people interact
with and are already used to
and I respect that.

Have a nice weekend,
Marek

>
>
> Vernon Schryver    vjs at rhyolite.com
> _______________________________________________
> ratelimits mailing list
> ratelimits at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/ratelimits


More information about the ratelimits mailing list