Re: Transport requirements for DNS-like protocols

Michael Mealling <michael@neonym.net> Fri, 28 June 2002 12:46 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00A0424PNH@eListX.com> (original mail from michael@bailey.dscga.com) ; Fri, 28 Jun 2002 08:46:02 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00A0124PNF@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 08:46:01 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00A0124PNE@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 08:46:01 -0400 (EDT)
Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GYF00A0924OL1@eListX.com> for ietf-irnss@lists.elistx.com; Fri, 28 Jun 2002 08:46:01 -0400 (EDT)
Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g5SCiOuK007610; Fri, 28 Jun 2002 08:44:24 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g5SCiO8B007609; Fri, 28 Jun 2002 08:44:24 -0400 (EDT)
Date: Fri, 28 Jun 2002 08:44:23 -0400
From: Michael Mealling <michael@neonym.net>
Subject: Re: Transport requirements for DNS-like protocols
In-reply-to: <15430645.1025273478@localhost>
To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <paf@cisco.com>
Cc: Rob Austein <sra@hactrn.net>, ietf-irnss@lists.elistx.com
Reply-to: Michael Mealling <michael@neonym.net>
Message-id: <20020628084423.V24592@bailey.dscga.com>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
Content-disposition: inline
User-Agent: Mutt/1.3.22.1i
References: <199812050411.UAA00462@daffy.ee.lbl.gov> <vern@ee.lbl.gov> <20020628034133.D50C518AC@thrintun.hactrn.net> <15430645.1025273478@localhost>
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>

On Fri, Jun 28, 2002 at 02:11:18PM +0200, Patrik Fältström wrote:
> --On 2002-06-27 23.41 -0400 Rob Austein <sra@hactrn.net> 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.

I have to agree. Our experience running .com suggests that, due to 
the scale of queries, any small percentage change in processing requirements
on the server side results in huge swings in operational requirements
that affect the entire robustness of the system. 

I think that's a valuable enough guideline to warrant putting it into at
least the SLS document I'm working on...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
michael@neonym.net      |                              | http://www.neonym.net