dns-search: draft section 3.6.2 on caching

John C Klensin <klensin@jck.com> Fri, 28 June 2002 22:50 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00804U3ER5@eListX.com> (original mail from klensin@jck.com); Fri, 28 Jun 2002 18:50:02 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00801U3ER3@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 18:50:02 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00801U3ER2@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 18:50:02 -0400 (EDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GYF005G1U3DXG@eListX.com> for ietf-irnss@lists.elistx.com; Fri, 28 Jun 2002 18:50:01 -0400 (EDT)
Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17O4Ym-000Eyc-00 for ietf-irnss@lists.elistx.com; Fri, 28 Jun 2002 22:49:48 +0000
Date: Fri, 28 Jun 2002 18:49:48 -0400
From: John C Klensin <klensin@jck.com>
Subject: dns-search: draft section 3.6.2 on caching
To: ietf-irnss@lists.elistx.com
Message-id: <12233653.1025290188@localhost>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.0a3 (Win32)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
List-Owner: <mailto:ietf-irnss-help@lists.elistx.com>
List-Post: <mailto:ietf-irnss@lists.elistx.com>
List-Subscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-irnss/>
List-Help: <http://lists.elistx.com/elists/admin.shtml>, <mailto:ietf-irnss-request@lists.elistx.com?body=help>
List-Id: <ietf-irnss.lists.elistx.com>

Hi.  The text that follows is the current draft of section 3.6.2
of the new dns-search document (section numbers correspond to
those of the draft-klensin-dns-search-03.txt, now in the
archives).

It reflects parts of today's discussion as well as some earlier
text.

Comments welcome up to late Sunday US EDT, at which time the
document will go into the I-D posting process (and I'll try to
post an FTP location for those who are impatient).

    john

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

3.6.2 The cache model

The model proposed here is ultimately one of "searching" --
finding a resource in a way that may involve some interaction
between the various databases and the user.  It differs from the
"search engine" approach because the databases are intentionally
populated (not unlike the DNS although syntax and semantics are
different) and the searches are highly structured.  In the
"search engines", the databases are largely populated by
automated processes that walk through the Internet (or the web)
picking up data of possible interest.  And the queries use, at
most, boolean conditions, not a structured, faceted,
architecture.  The obvious advantage of a search technique of
this sort is that it should have good odds of permitting owners
or operators of resources who wish those resources to be found
to have them efficiently found by those who are looking for
them.  But it is unlikely that the process can be made as fast
or resource-minimizing as a DNS lookup where the fully-qualified
domain name is already known.

At the same time, the nature of the systems being proposed makes
it likely that a user will think of a particular resource (or
its location) in terms of the terminology used to find it.  And,
especially if the user needs to be involved in the search and
resolution process to identify a resource (or resources) of
interest from among those that match a set of facets, users will
not tolerate having to go through the process on every
reference.  The combination of these factors makes it almost
essential that it be possible to maintain a local table of
references and targets (in DNS or URL terms) so that additional
references soon after the first can be used by protocols to
directly access recently-used targets without having to go
through the search and resolution process each time.

Even "soon" may be quite different from our experience with the
DNS. With the DNS, the resources bound to names are typically IP
addresses or something similar, and these change frequently
enough, often on short notice, that "time to live" (TTL) values
are typically short, rarely more than a day.  By contrast, the
faceted name of a sublayer two search is likely to represent a
fairly long-lived relationship with the DNS names and URLs that
it identifies.  Clearly, it should be convenient for the user to
reinitiate the search when that is obviously needed (e.g., if a
target goes bad) but TTLs for ordinary refreshing of a search
will, in most cases, be set closer to the order of weeks than to
minutes or hours, with the DNS taking responsibility for the
volatile portion of the references, as it does today.

A facility similar to this is provided for web browsers by the
common "bookmarks" or "favorites" functions, but those do not
support the functionality that will be necessary for caching
operations in this sublayer two search environment.

The sublayer two search entries ("bookmarks" or "favorites" if
it is useful to think of them that way) can be thought of as a
local cache of queries and responses with sufficient information
to both immediately locate a target associated with the user's
perception of what was looked for and of "refreshing" the search
if circumstances changed or values timed out.  In the presence
of a particular query, a client system would presumably check
for a matching bookmark.  If one was not found, the layer two
search would be performed, yielding values that might require
user intervention for selection.  Once selected, the search, the
full set of facets returned, the DNS names or URIs, and any TTL
information would be stored (possibly using a user-supplied name
or tag) and the resource accessed via the appropriate DNS name
or URI.  If the search or tag was found in the cache, checks
would be made for the values being current and then the DNS name
or URI used directly, without going back through the search
procedure.

One useful consequence of this is that the number of queries to
the database will be roughly proportionate to the number of new
inquiries by the user (increased by the impact of TTL timeout
and user-initiated repeated search.  That number should be much
smaller, and hence imply significantly less load, than
per-reference DNS queries.