Re: Transport requirements for DNS-like protocols

John C Klensin <klensin@jck.com> Fri, 28 June 2002 14:50 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00E047VF0D@eListX.com> (original mail from klensin@jck.com); Fri, 28 Jun 2002 10:50:03 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00E017VF0B@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 10:50:03 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00E017VF0A@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 10:50:03 -0400 (EDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GYF00D0J7VEYP@eListX.com> for ietf-irnss@lists.elistx.com; Fri, 28 Jun 2002 10:50:02 -0400 (EDT)
Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17Nx3y-0003im-00; Fri, 28 Jun 2002 14:49:30 +0000
Date: Fri, 28 Jun 2002 10:49:28 -0400
From: John C Klensin <klensin@jck.com>
Subject: Re: Transport requirements for DNS-like protocols
In-reply-to: <15930740.1025281814@localhost>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>, Rob Austein <sra@hactrn.net>, ietf-irnss@lists.elistx.com
Message-id: <80592004.1025261368@localhost>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.0a3 (Win32)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE
Content-disposition: inline
References: <199812050411.UAA00462@daffy.ee.lbl.gov> <vern@ee.lbl.gov> <20020628034133.D50C518AC@thrintun.hactrn.net> <15430645.1025273478@localhost> <75776902.1025256553@localhost> <15930740.1025281814@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>

Exactly.
    john


--On Friday, 28 June, 2002 16:30 +0200 Patrik Fältström
<paf@cisco.com> wrote:

> --On 2002-06-28 09.29 -0400 John C Klensin <klensin@jck.com>
> wrote:
> 
>> 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.
> 
> Agreed. And, another reason why one want to do more
> calculations on the server side is because differentiation
> between services. I.e. if we look at systems which does not
> work like the DNS (where koherence is extremely important, and
> together with caching create a very very special constrain),
> we can allow different servers to do different things. Some
> servers should be able to be "better" for chemistry than
> others.
> 
> So, I would like to see something where both server and client
> side can do good things, because at the end the user using the
> client want to have "correct" results back.
> 
> My point with saving CPU in the server is just because too
> many don't think about the fact that a server can not spend
> more time on a query than the time between queries. Yes, via
> parallell threads in the server this is possible, but only to
> a certain degree. The server need to at least get rid of
> responses in the same speed new queries are coming in.
> 
> Now, this create problem if we mix "large data sets" with
> "many queries".
> 
> We make the problem easier to solve if we have the ability to
> inside the protocol do things which DNS can not handle:
> 
>  - Split one dataset on more than one server, so the dataset
> can    always be arbitrary small (a zone in DNS is a zone...is
> a zone)
> 
>  - Split the query load on more than one server, so the query
>    load can be shared (which imply that the server should not
>    keep state -- if at all possible)
> 
> With simple things like this, we will get much easier
> operations than what we have today in many protocols (DHCP,
> DNS etc).
> 
>    paf
> 
> 
>