[Dundi] Caching

[John Todd]

At 3:27 PM -0500 on 10/22/04, Mark Spencer wrote:
>I left caching off my "todo" list earlier.  It's going to be 
>important to decide what the best cache time is.  Obviously the 
>longer the cache time, the fewer wasted transactions there are, but 
>at the same time, the longer it can take for a number relocation to 
>take effect.
>
>Right now the cache is set at 3600 seconds, or one hour.  I think 
>we're going to have to revisit this eventually.  Would a cache time 
>of 24 hours be unreasonable?  What about caching "hints" for 24 
>hours and caching numbers for less?
>
>Mark

I think numbers for 24 hours is reasonable as a default.  In fact, 
I'd opt for even longer, since telephony routes are far less subject 
to change than the IP routes on which they rely.  Would I be safe in 
saying that the longer the cache time, the more efficient the network 
delivers replies in a steady-state environment?  The trick is then to 
measure what "steady-state" is and see where the benefits of larger 
cache stop outweighing the problems associated with stale cached data.

You had mentioned cache times being specifiable by the originating 
entity; is this currently a context-by-context thing or is it a 
hardcoded value right now?

The concept of cache time eventually brings one around to the concept 
of negative caching, or viewed another way: removal of routes based 
on (direct or indirect?) peers being invalidated for some reason. 
Since this does not seem to be a link-state protocol, what are the 
"certain conditions" under which that might happen?   I can't think 
of any way that seems to work from various perspectives.  You 
probably don't want to invalidate routes because you can't see the 
announcing host any more, because the DUNDi-speaker may not be the 
host that takes the "call".

JT