Re: Transport requirements for DNS-like protocols

Patrik Fältström <paf@cisco.com> Fri, 28 June 2002 14:47 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00D047RRYY@eListX.com> (original mail from paf@cisco.com); Fri, 28 Jun 2002 10:47:51 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00D017RQYW@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 10:47:50 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00D017RQYV@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 10:47:50 -0400 (EDT)
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GYF00D027RPYP@eListX.com> for ietf-irnss@lists.elistx.com; Fri, 28 Jun 2002 10:47:50 -0400 (EDT)
Received: from xbe-lon-303.cisco.com (xbe-lon-303.cisco.com [64.103.98.22]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5SEkJVc017923; Fri, 28 Jun 2002 16:46:19 +0200 (MET DST)
Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 28 Jun 2002 15:47:03 +0100
Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 28 Jun 2002 16:47:02 +0200
Date: Fri, 28 Jun 2002 16:30:14 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Subject: Re: Transport requirements for DNS-like protocols
In-reply-to: <75776902.1025256553@localhost>
To: John C Klensin <klensin@jck.com>, Rob Austein <sra@hactrn.net>, ietf-irnss@lists.elistx.com
Message-id: <15930740.1025281814@localhost>
MIME-version: 1.0
X-Mailer: Mulberry/2.2.0 (Mac OS X)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
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>
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>
X-OriginalArrivalTime: 28 Jun 2002 14:47:02.0791 (UTC) FILETIME=[AA2D6970:01C21EB2]

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