[Dundi] Caching
John Todd
jtodd at loligo.com
Sat Oct 23 17:29:51 CDT 2004
At 4:55 PM -0500 on 10/23/04, Mark Spencer wrote:
>> I would rather see a mechanism for Announcers to push changes into
>>the peer group. Changes delays then become a function of convergence time
>>rather than TTL.
>
>This becomes totally unmanagable with a large system because
>essentially every node must know the routes for all numbers as they
>come and go. Definitely a bad idea. However, we recently added a
>"PRECACHE" function to DUNDI so that, for example, smaller nodes
>could "PRECACHE" answers up to a more master node.
>
>If this works, then we could setup a "best practices" policy that
>nodes with less than a thousand (or whatever the magic number is)
>routes would simply "PRECACHE" their answers up to one or two other
>nodes, rather than actually be queried the whole time.
>
>What do people think about this?
I think that's reasonable. At a minimum, it would allow for much
faster lookup times in an enterprise environment that was
topologically distributed by allowing a full cache push. Even a 1 or
2 second delay in some companies during a number lookup is perceived
to be "too long". Whaddevah.
The trick on this is enforcement of the "magic" number by the caching
host. In other words, don't let someone dump a million routes into
your cache. If you want to protect the core, some type of backoff is
required when accepting large amounts of updates. Careful that this
is configurable; there may be some nodes that due to natural growth
will see loads that appear to be flooding of pre-cache data, so this
needs to be a turnable knob.
I'd say that as a start, 1000 numbers would be reasonable as a
hardcoded default as a precache push if that option was turned on on
the "announcer". Similarly, 1000 numbers within 10 seconds might be
a reasonable trigger (rolling average?) at which a "listener" would
start to back off or slow down ACKs. Again, this should be able to
be tuned per DUNDi "peer", as some people won't care or will want a
more aggressive cache pre-population. Also, putting in a slowdown
for ACKs might also be able to prevent some inadvertent DOS attacks
due to misconfiguration - I can't think of an exact instance where
that would be the case right now, but I've seen some really whacky
dialplans that might cause lots of headaches for peers.
JT
More information about the Dundi
mailing list