Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt

[Warren Kumari <[e-mail]>]

On Jul 3, 2013, at 5:14 PM, Paul Hoffman <[e-mail]> wrote:

> On Jul 3, 2013, at 2:01 PM, "John Levine" <[e-mail]> wrote:
> 
>>>>>  If yes, message cache elements are prefetched before they expire
>>>>>  to  keep  the  cache  up to date.  Default is no.  Turning it on
>>>>>  gives about 10 percent more traffic and load on the machine, but
>>>>>  popular items do not expire from the cache.
>> 
>>> My question earlier still stands: does Unbound do what HAMMER says
>>> (waits for a request before refreshing the cache) or does it just
>>> refresh the cache automatically? The Unbound doc is unclear (at least
>>> to me).
>> 
>> If it did it automatically, I'd expect a lot more than 10% more
>> traffic.  I enabled it on my not terribly busy server and I see
>> numbers that look like they're in the 1% range:
>> 
>> Jul 03 14:23:21 unbound[40669:0] info: server stats for thread 0: 47798 queries, 20108 answers from cache, 27690 recursions, 242 prefetch
>> Jul 03 15:23:21 unbound[40669:0] info: server stats for thread 0: 53322 queries, 20319 answers from cache, 33003 recursions, 291 prefetch
>> Jul 03 16:23:21 unbound[40669:0] info: server stats for thread 0: 55260 queries, 20697 answers from cache, 34563 recursions, 272 prefetch
>> 
> 
> Those are pictures. Source code, or developer assurance, or it didn't happen ( to badly bastardize a phrase that the kids these days use ).

It *appears* to me from looking at the source that Unbound triggers upon an incoming query (basically what HAMMER suggests).
I should note that this is the first time I have looked at the Unbound source, and so it is entirely possible that I'm missing something.

It seems that worker_handle_request() in worker.c has the interesting bits.
From what I can tell, the worker will only have this sort of request if it was initiated by an incoming query.

Horrendous pseudocode seems like:
worker_handle_request()
 if answer_from_cache:
    if prefetch_ttl_expired:
       reply_and_prefetch()


/** Reply to client and perform prefetch to keep cache up to date */
reply_and_prefetch() 
  reply()
    /* create the prefetch in the mesh as a normal lookup without
	 * client addrs waiting, which has the cache blacklisted (to bypass
	 * the cache and go to the network for the data). */
	/* this (potentially) runs the mesh for the new query */
    	mesh_new_prefetch(worker->env.mesh, qinfo, flags, leeway + 
		PREFETCH_EXPIRY_ADD);


There is also a PREFETCH_EXPIRY_ADD which I don't really understand:

/** 
 * seconds to add to prefetch leeway.  This is a TTL that expires old rrsets
 * earlier than they should in order to put the new update into the cache.
 * This additional value is to make sure that if not all TTLs are equal in
 * the message to be updated(and replaced), that rrsets with up to this much
 * extra TTL are also replaced.  This means that the resulting new message
 * will have (most likely) this TTL at least, avoiding very small 'split
 * second' TTLs due to operators choosing relative primes for TTLs (or so).
 * Also has to be at least one to break ties (and overwrite cached entry).
 */
#define PREFETCH_EXPIRY_ADD 60

I must admit that I'm somewhat shaky on much of the above, it would be great if someone who is more familiar with the architecture / code could comment/


W




> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

-- 
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.  
    -- J.R.R. Tolkien