RE: Transport requirements for DNS-like protocols
Nicolas Popp <nico@realnames.com> Fri, 28 June 2002 17:30 UTC
Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00I04FB0OE@eListX.com> (original mail from nico@realnames.com); Fri, 28 Jun 2002 13:30:36 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00I01FAZOC@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 13:30:35 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00I01FAZOB@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 13:30:35 -0400 (EDT)
Received: from friendly.realnames.com (friendly.realnames.com [63.251.238.102]) by eListX.com (PMDF V6.0-025 #44856) with SMTP id <0GYF00H8FFAYKD@eListX.com> for ietf-irnss@lists.elistx.com; 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 nico@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.857672 secs); Fri, 28 Jun 2002 17:30:21 +0000
Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; Fri, 28 Jun 2002 17:30:19 +0000
Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:4163]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <945278@heaven.internal.realnames.com> for <michael@neonym.net>; Fri, 28 Jun 2002 10:24:10 +0000 (AM)
Received: by rincon.centraal.com 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 <nico@realnames.com>
Subject: RE: Transport requirements for DNS-like protocols
To: 'Michael Mealling' <michael@neonym.net>, John C Klensin <klensin@jck.com>
Cc: Patrik Fältström <paf@cisco.com>, Rob Austein <sra@hactrn.net>, ietf-irnss@lists.elistx.com
Message-id: <7FC3066C236FD511BC5900508BAC86FED21D3B@trestles.internal.realnames.com>
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: <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 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. -Nico -----Original Message----- From: Michael Mealling [mailto:michael@neonym.net] Sent: Friday, June 28, 2002 7:05 AM To: John C Klensin Cc: Patrik Fältström; Rob Austein; ietf-irnss@lists.elistx.com 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".... >
- 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