[Dundi] Caching

[Mark Spencer]

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

Right, and I plan to add some statistics to let us:

1) Find out what the economic benefit of DUNDi is (What % of calls go over 
IP)

2) Track down which nodes at each tier are slowing down queries, so that 
if the system starts to bog down we can better find out who needs to 
restructure (e.g. move to a PRECACHE model).

3) Determine what precentage of queries are cache hits (increasing the 
cache time would increase that percentage).

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

Currently it's hard coded, but yes, it would be a context/mapping specific 
thing and a set of global defaults.

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

Typically you would not invalidate routes at all, you would wait for the 
cache time to expire, and when given a route you would qualify it for 
yourself.  Remember that within E.164, the GPA requires you provide 
Congestion if you cannot terminate the call.

Mark