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: Patrik Fältström <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
- 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