Re: Transport requirements for DNS-like protocols

Michael Mealling <> Fri, 28 June 2002 14:07 UTC

Return-Path: <>
Received: from by (PMDF V6.0-025 #44856) id <> (original mail from ; Fri, 28 Jun 2002 10:07:18 -0400 (EDT)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Fri, 28 Jun 2002 10:07:18 -0400 (EDT)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Fri, 28 Jun 2002 10:07:18 -0400 (EDT)
Received: from ( []) by (PMDF V6.0-025 #44856) with ESMTP id <> for; Fri, 28 Jun 2002 10:07:17 -0400 (EDT)
Received: from (localhost []) by (8.12.1/8.12.1) with ESMTP id g5SE54uK007867; Fri, 28 Jun 2002 10:05:04 -0400 (EDT)
Received: (from michael@localhost) by (8.12.1/8.12.1/Submit) id g5SE53I2007866; Fri, 28 Jun 2002 10:05:03 -0400 (EDT)
Date: Fri, 28 Jun 2002 10:05:03 -0400
From: Michael Mealling <>
Subject: Re: Transport requirements for DNS-like protocols
In-reply-to: <75776902.1025256553@localhost>
To: John C Klensin <>
Cc: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <>, Rob Austein <>,
Reply-to: Michael Mealling <>
Message-id: <>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
Content-disposition: inline
User-Agent: Mutt/
References: <> <> <> <15430645.1025273478@localhost> <75776902.1025256553@localhost>
List-Owner: <>
List-Post: <>
List-Subscribe: <>, <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Help: <>, <>
List-Id: <>

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"....

> --On Friday, 28 June, 2002 14:11 +0200 Patrik Fältström
> <> wrote:
> > --On 2002-06-27 23.41 -0400 Rob Austein <> wrote:
> > 
> >> It's not a big deal for the server to perform the entire
> >> query operation again.
> > 
> > ...given the matching operation is cheap. I.e. what you don't
> > say explicitly is that we should use as much as possible of
> > the CPU on the client side.
> > 
> > This is one of the reasons why I when I came up with IDNA want
> > the client to do the normalization etc, so the server can do
> > bitwise comparison which make handling of hash tables easier.
> > 
> > I am very nervous when people come up with protocols where the
> > client can pass whatever constraints to the server, and
> > request the server to do complicated things. Things which is
> > easy when you have an MySQL database with 100 records, but,
> > when you have more data in the database than what fits in
> > primary memory, then you loose.
> > 
> >    paf -- with tons of experience regarding "hitting the wall"
> > regarding           implementation of databases etc
> Yes, but...  If one can keep the operations sufficiently simple
> (e.g., no profiles and few or none of the constraints you are
> concerned about), there are very significant advantages to
> server-side operations, particularly to interoperability,
> getting things right, and being able to do upgrades/ changes in
> a rational way. Based on some experience with very large
> databases involving a high ratio of queries to updates, I think
> one can go well beyond bitwise comparison and still have that be
> true, at least given reasonable database design.

I really think some cost/benifit analysis with an input from Moore's Law
would be helpful. Simply saying that "server side operations = bad"
isn't sufficient. Certain complex operations would be but its not
that simple. Part of the problem is that we don't know how to do the
analysis. If the benifit is high enough (a true multilingual Internet)
does it become desirable at any cost? Some would say yes and happily go out
and build co-located server farms with literally thousands of machines.
I wouldnt' agree with them but we have to be really careful how we
address this. 

<thinking out loud>
My gut level, first reaction is that simple computation and byte-level
lookup is fine. Things like per-user customized queries, attempts at
anything like natural language would break that barrier. These things
would be very appropriate for Layer 3 type services but not for Layer 2.
But I can't really put my finger on how I'm making those decisions...
I guess it has something to do with being able to treat each query the
same and utilizing the fastest parts of the system (simple, non-conditional
and deterministic computation backed up with octet-wise database lookup). 
</thinking out loud>


Michael Mealling	|      Vote Libertarian!       | urn:pin:1      |                              |