RE: Transport requirements for DNS-like protocols

Nicolas Popp <> Fri, 28 June 2002 17:30 UTC

Return-Path: <>
Received: from by (PMDF V6.0-025 #44856) id <> (original mail from; Fri, 28 Jun 2002 13:30:36 -0400 (EDT)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Fri, 28 Jun 2002 13:30:35 -0400 (EDT)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Fri, 28 Jun 2002 13:30:35 -0400 (EDT)
Received: from ( []) by (PMDF V6.0-025 #44856) with SMTP id <> for; Fri, 28 Jun 2002 13:30:35 -0400 (EDT)
Received: (qmail 18500 invoked by uid 104); Fri, 28 Jun 2002 17:30:21 +0000
Received: from by with qmail-scanner-0.96 (. Clean. Processed in 0.857672 secs); Fri, 28 Jun 2002 17:30:21 +0000
Received: from ( by with SMTP; Fri, 28 Jun 2002 17:30:19 +0000
Received: From RINCON.INTERNAL.REALNAMES.COM ([ port:4163]) by Mail essentials (server 2.422) with SMTP id: <> for <>; Fri, 28 Jun 2002 10:24:10 +0000 (AM)
Received: by with Internet Mail Service (5.5.2653.19) id <KHQCNBHY>; Fri, 28 Jun 2002 10:30:14 -0700
Date: Fri, 28 Jun 2002 10:24:55 -0700
From: Nicolas Popp <>
Subject: RE: Transport requirements for DNS-like protocols
To: 'Michael Mealling' <>, John C Klensin <>
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <>, Rob Austein <>,
Message-id: <>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE
List-Owner: <>
List-Post: <>
List-Subscribe: <>, <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Help: <>, <>
List-Id: <>

On the client versus server discusssion, I strongly disagree with any
approach that requires pre-processing on the client, even localization /
normalization type of processing. John has already emphasized some of the
main advantages to putting the IRNSS smart on the server side. I would add
to that the issue of writing, maintaining and pushing new client codes which
over time becomes a huge penalty that our design should minimize if not
preclude, especially if we want to make IRNSS real in our lifetime (I would
have hoped that the slowness of IDNA deployment had made it clear by now). 

Also note that the name-string pre-processing (normalization and so forth)
which is CPU bound is relatively cheap on the server side (more importantly
highly predictable so that you can adjust your number of servers to query
rates). What is always much much much more costly is records lookup form the
data store. As soon as you do fuzzy matching that forces you to retrieve
multiple records and rank them, the operational complexity is increased
ten-fold (and your query response time becomes way more inpredictable unless
you do a few "right things"). At that point, the string pre-processing time
becomes relatively irrelevant and you may as well go all the way and do
everything on the server side. That way, your client libraries are trivial
to develop and maintain across OS platforms, client application and devices.

On the other hand, I agree that we should design IRNSS with  server-side
optimizations in mind (such as data set distribution, caching strategies and
stateless servers...).

Lastly, operations wise, don't you think that an IRNSS name service will be
closer to a search engine than DNS? In fact, I would anticipate that most of
the traffic will still be repeat traffic using straight layer 1 identifiers.


-----Original Message-----
From: Michael Mealling []
Sent: Friday, June 28, 2002 7:05 AM
To: John C Klensin
Cc: Patrik Fältström; Rob Austein;
Subject: Re: Transport requirements for DNS-like protocols

On Fri, Jun 28, 2002 at 09:29:13AM -0400, John C Klensin wrote:
> (Note to readers of this list other than Patrik and Rob...
> Patrik has raised, in conjunction with this "transport
> requirements" discussion, a rather fundamental design issue.

Very fundamental and very important, especially if you ever aspire
to running something even a fraction of the size of ".com"....