BIND 10 resolver_research_and_design, updated. 07738f9d7122d58dd7e42b7fc414f46c3f5ede35 Some starting questions for recursive resolver research.

[BIND 10 source code commits]

The branch, resolver_research_and_design has been updated
       via  07738f9d7122d58dd7e42b7fc414f46c3f5ede35 (commit)
      from  7da8c5f511ba519a582e5c9828b74de03651f701 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 07738f9d7122d58dd7e42b7fc414f46c3f5ede35
Author: Shane Kerr <shane at isc.org>
Date:   Tue Feb 19 14:58:35 2013 +0100

    Some starting questions for recursive resolver research.

-----------------------------------------------------------------------

Summary of changes:
 doc/design/resolver/01-scaling-across-cores        |   21 +++++++++++++++
 .../resolver/02-mixed-recursive-authority-setup    |   28 ++++++++++++++++++++
 doc/design/resolver/03-cache-algorithm             |   22 +++++++++++++++
 doc/design/resolver/README                         |    5 ++++
 4 files changed, 76 insertions(+)
 create mode 100644 doc/design/resolver/01-scaling-across-cores
 create mode 100644 doc/design/resolver/02-mixed-recursive-authority-setup
 create mode 100644 doc/design/resolver/03-cache-algorithm
 create mode 100644 doc/design/resolver/README

-----------------------------------------------------------------------
diff --git a/doc/design/resolver/01-scaling-across-cores b/doc/design/resolver/01-scaling-across-cores
new file mode 100644
index 0000000..8fc376b
--- /dev/null
+++ b/doc/design/resolver/01-scaling-across-cores
@@ -0,0 +1,21 @@
+01-scaling-across-cores
+
+Introduction
+------------
+The general issue is how to insure that the resolver scales.
+
+Currently resolvers are CPU bound, and it seems likely that both
+instructions-per-cycle and CPU frequency will not increase radically,
+scaling will need to be across multiple cores.
+
+How can we best scale a recursive resolver across multiple cores?
+
+Some possible solutions:
+
+a. Multiple processes with independent caches
+b. Multiple processes with shared cache
+c. A mix of independent/shared cache
+d. Thread variations of the above
+
+All of these may be complicated by NUMA architectures (with
+faster/slower access to specific RAM).
diff --git a/doc/design/resolver/02-mixed-recursive-authority-setup b/doc/design/resolver/02-mixed-recursive-authority-setup
new file mode 100644
index 0000000..84658ef
--- /dev/null
+++ b/doc/design/resolver/02-mixed-recursive-authority-setup
@@ -0,0 +1,28 @@
+02-mixed-recursive-authority-setup
+
+Introduction
+------------
+Ideally we will run the authoritative server independently of the
+recursive resolver.
+
+We need a way to run both an authoritative and a recursive resolver on
+a single platform, listening on the same IP/port.
+
+We have 3 basic components involved in this mix:
+
+1. Authoritative zones
+2. Cached RRSETs
+3. Non-cached information
+
+There are a number of possible approaches to this:
+
+a. Make a module that includes all logic. (The BIND 9 module?)
+b. Look at authoritative server first, and pass queries to the
+   recursive component.
+c. Make a module that combines authoritative and cache. Queries not
+   found get passed to a resolver, which also has to update the cache.
+d. Have a simple "receptionist" module which knows which zones we are
+   authoritative for and sends all queries to another daemon.
+
+Stephen did some modeling work on this already. We need to understand
+the latency and throughput implications of any of these approaches.
diff --git a/doc/design/resolver/03-cache-algorithm b/doc/design/resolver/03-cache-algorithm
new file mode 100644
index 0000000..42bfa09
--- /dev/null
+++ b/doc/design/resolver/03-cache-algorithm
@@ -0,0 +1,22 @@
+03-cache-algorithm
+
+Introduction
+------------
+Cache performance may be important for the resolver. It might not be
+critical. We need to research this.
+
+One key question is: given a specific cache hit rate, how much of an
+impact does cache performance have?
+
+For example, if we have 90% cache hit rate, will we still be spending
+most of our time in system calls or in looking things up in our cache?
+
+There are several ways we can consider figuring this out, including
+measuring this in existing resolvers (BIND 9, Unbound) or modeling
+with specific values.
+
+Once we know how critical the cache performance is, we can consider
+which algorithm is best for that. If it is very critical, then a
+custom algorithm designed for DNS caching makes sense. If it is not,
+then we can consider using an STL-based data structure.
+
diff --git a/doc/design/resolver/README b/doc/design/resolver/README
new file mode 100644
index 0000000..b6e9285
--- /dev/null
+++ b/doc/design/resolver/README
@@ -0,0 +1,5 @@
+This directory contains research and design documents for the BIND 10
+resolver reimplementation.
+
+Each file contains a specific issue and discussion surrounding that
+issue.