[bind10-dev] recursor cache requirements (better explanation of the cookie idea)

[Michal 'vorner' Vaner]

Hello

On Fri, Dec 17, 2010 at 10:59:09AM +0100, Michal 'vorner' Vaner wrote:
> I'd like to point out that NSAS as is will not work without them and that they
> are different concept than the L1/L2 cache (even if it might be implemented in
> a similar manner inside).

As it turned out, the idea of cache cookies is not entirely clear, so let me try
to explain it little bit more.

First, I'll explain why it is needed by NSAS. Currently, NSAS uses resolver to
get NS records for a zone and A and AAAA records for the nameservers. Which
means it relies on the resolver to use the glue.

The nice flow of events would be:
1. Resolver asks a remote nameserver something.
2. The nameserver responds by a referral, providing the name of the zone to
   follow and glue.
3. The complete answer, including the glue, is stored in cache.
4. The resolver looks and asks NSAS what the IP address of some nameserver of the
   zone might be.
5. NSAS does not know, so it asks resolver for NS records and then A records.
6. Resolver looks into the cache and finds it there, because we got it as the
   glue.
7. NSAS gives an IP address to the resolver.
8. The resolver can ask the nameserver and everyone lives happily ever after.

Now, the bad thing that can happen. The glue has TTL 0 or the cache is small.
So, the point 6. and following changes:
6. It is not in the cache any more, it expired/has been evicted.
7. Resolver decides it needs to ask remote nameserver. It finds out there's a
   zone of this name so it asks NSAS.
8. NSAS still does not know, it waits for the resolver to give the NS records.
   But the resolver can't, it waits for the IP address. So NSAS just batches the
   request together with the original one and waits.
9. At some point, a timeout happens and the user is unsatisfied, because she
   can't get to her favorite web page.

So, the proposal of cache cookies tries to solve this. It would work like this:
…
3. The complete answer, including the glue, is stored in cache and a cache
   cookie is issued. The cookie guarantees any component that has it that the
   cache will contain at last the records that were just stored in at last as
   good quality.
4.-6. The same, but the cookie is carried together with it. So, in 6., even when
   the TTL is 0, we can be sure we will get the glue, because we have the cookie.


Now, how it is different from the L1 cache. From the interface/logic point of
view:
• There's only one L1 cache, but there might be any number of cache cookies at
  the same time.
• The L1 cache is never destroyed, it is there for ever. The cookie is
  destroyed once it is not needed, allowing the deletion of given records.
• The L1 cache never leaves the cache component and is internal to it. Cache
  cookies travel around and can be passed back to the cache at some point, but
  the cache shouldn't care about them, they are not owned by it.
• The L1 have precedence over L2 (in a sense when there is a record in both, we
  take the one from L1, or put differently, we look into L1 first). But cache
  cookie has low precedence (we look into L1, then to L2 and when still nothing
  there, we have a look into the cookie). This ensures that we provide better
  quality RRset if we have it than the glue (for example never instance of it,
  or from authoritative source).

From the implementation point of view, they are similar (or, can be):
• Each of L1, L2 and cache cookie contain a hash table with shared pointers to
  data.
• The precedence of L1, L2 and cache cookie can be carried in the same way.

The difference is, though:
• The cache cookie doesn't need whole messages. RRsets are enough, because NSAS
  asks for a given RRset. Or, I hope it doesn't need them.
• The L1 is inside the cache. The cookies get trough the interface out and the
  cache never cares about them until they come back by the interface.


Sorry for such a long email, but I hope it helps understanding what I mean.

Have a nice day

-- 
Never underestimate the bandwidth of a station wagon full of HDDs.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101220/cbac8d17/attachment.bin>