Re: Transport requirements for DNS-like protocols
Michael Mealling <michael@neonym.net> Fri, 28 June 2002 14:07 UTC
Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00C045W6I6@eListX.com> (original mail from michael@bailey.dscga.com) ; Fri, 28 Jun 2002 10:07:18 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00C015W6I4@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 10:07:18 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00C015W6I3@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 10:07:18 -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 <0GYF00ADJ5W4L1@eListX.com> for ietf-irnss@lists.elistx.com; Fri, 28 Jun 2002 10:07:17 -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 g5SE54uK007867; Fri, 28 Jun 2002 10:05:04 -0400 (EDT)
Received: (from michael@localhost) by bailey.dscga.com (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 <michael@neonym.net>
Subject: Re: Transport requirements for DNS-like protocols
In-reply-to: <75776902.1025256553@localhost>
To: John C Klensin <klensin@jck.com>
Cc: Patrik Fältström <paf@cisco.com>, Rob Austein <sra@hactrn.net>, ietf-irnss@lists.elistx.com
Reply-to: Michael Mealling <michael@neonym.net>
Message-id: <20020628100503.X24592@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> <75776902.1025256553@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 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 > <paf@cisco.com> 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. > > > > 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> -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net
- Re: Transport requirements for DNS-like protocols John C Klensin
- RE: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Dave Crocker
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- Re: Transport requirements for DNS-like protocols Dave Crocker
- RE: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols Rob Austein
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- RE: Transport requirements for DNS-like protocols John C Klensin
- RE: Transport requirements for DNS-like protocols Nicolas Popp
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Eric Brunner-Williams in Portland Maine
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols John C Klensin
- Re: Transport requirements for DNS-like protocols Michael Mealling
- Re: Transport requirements for DNS-like protocols Patrik Fältström
- Transport requirements for DNS-like protocols Rob Austein
- RE: Transport requirements for DNS-like protocols Patrik Fältström
- RE: Transport requirements for DNS-like protocols John C Klensin
- RE: Transport requirements for DNS-like protocols Patrik Fältström