[bind10-dev] Planning for next sprint - input required

[Michal 'vorner' Vaner]

Hello

Here is some feedback, which is partially some unsorted ideas of what might need
to be done, what depends on what. I'm not sure if this is the needed kind of
feedback, it just crossed my mind when I read the topics. Hopefully they would
be of some use.

On Thu, Nov 25, 2010 at 06:25:41PM +0000, Stephen Morris wrote:
> In the short term thought, the six-week release cycle is coming to an end next week.  At the planning meetings next week, we need to assess where we are and what we achieved, decide what our goals are for the following cycle and estimate/select the tasks appropriately.

From how I'm able to keep track of what is happening in the R team:
• There's one branch not merged to #327, there are some review comments on it,
  but I think it will be merged on Tuesday, give or take a day.
• I work on the NSAS currently and keep changing the interface slightly from
  time to time. But I think the interface is nearing a state where it can be
  used, thought the internals will be changed (or written). So if anything
  depends/wants to use that, it might have a chance, lets say, from the second
  half of the next sprint (if I assume that we will continue on NSAS ‒ I doubt
  it will be finished).

> Recursor
> ========
>
> [ ... ]
> 
> Cache
> * Basic design
> * Handling TTL expiration/cache cleaning
> * Caching negative responses
> * When to cache glue v when to cache authoritative data

As we talked on the phone, the NSAS probably will depend a lot on a cache and
that it will intercept everything that goes ever in.

I think it makes change to store just everything we do not have in a better
instance (I want to store unauthoritative data if I do not have authoritative,
but if I have authoritative, then I just ignore unauthoritative going around, if
I have authoritative and I see authoritative, then I at last update the TTL).

The best logic place for the cache seems to be just before the dispatch (is
dispatch the thing that sends a query and waits for an answer, when it comes, it
calls the correct callback), so it can either look it up or ask the remote
server, fill itself up by the data and pass it along.

As the proper cache is really needed and it takes time, but at last something
working might be needed for different work, we might want to do a prototype of
really non-compliant cache which would have 100-200 lines of code (probably
without tests, as it would be thrown away soon):
• Store anything.
• Pretend everything is authoritative.
• Pretend everything has infinite TTL.
• When it is overfull, just drop everything and start again.
• Use some kind of std::map or something.

I promised to write the idea down in more detail somewhen during the weekend and
see if it makes sense. I might write some broader idea of how the thing would
work and what would be needed from a component, so I can get some assumptions
for current work on NSAS and see what others think.

> * Pre-load cache?
>   - Testing (can set up cache in particular configuration)

Wouldn't just a loop passing it many packets be enough?

>   - Authoritative server on same system (can load authoritative data into cache)

Does it make sense to pre-load it? Shouldn't we use the data store backend in
that case? Because it can change and be generated (not finite amount of data for
example).

> - Nameserver address store
>   * NSAS persistence - dumping and loading
> 
> Notes: Work seems to be well under way here.  However, the ability to save and restore the address store (across server restarts) has been requested.

Storing triples nameserver-IP address-RTT should be enough, anything else might
survive in the cache and be reconstructed from there.

This will have to wait until NSAS is in more stable state.

With regards

-- 
This email has been checked by an automatic damage possibility check system.
It can contain harmful instructions if read backwards.
Internal checker ID: lacol.cr/cte/ << tlah ohce

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/20101126/1d5574f0/attachment.bin>