Re: [tae] The internet architecture

Thomas Narten <narten@us.ibm.com> Fri, 05 December 2008 15:40 UTC

Return-Path: <tae-bounces@ietf.org>
X-Original-To: tae-archive@ietf.org
Delivered-To: ietfarch-tae-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35743A6AF2; Fri, 5 Dec 2008 07:40:52 -0800 (PST)
X-Original-To: tae@core3.amsl.com
Delivered-To: tae@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6393628C14D; Fri, 5 Dec 2008 06:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.965
X-Spam-Level:
X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqSVAmkgAeXa; Fri, 5 Dec 2008 06:35:23 -0800 (PST)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 6CA9428C149; Fri, 5 Dec 2008 06:35:23 -0800 (PST)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB5EYjxb019029; Fri, 5 Dec 2008 09:34:45 -0500
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB5EZIQk179902; Fri, 5 Dec 2008 09:35:18 -0500
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB5EZHtM021930; Fri, 5 Dec 2008 09:35:17 -0500
Received: from cichlid.raleigh.ibm.com (sig-9-65-205-212.mts.ibm.com [9.65.205.212]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB5EZGHu021895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 09:35:17 -0500
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mB5EZFNp007644; Fri, 5 Dec 2008 09:35:15 -0500
Message-Id: <200812051435.mB5EZFNp007644@cichlid.raleigh.ibm.com>
To: Keith Moore <moore@network-heretics.com>
In-reply-to: <49384BCF.2080600@network-heretics.com>
References: <C15AE32B-E564-4C93-86FF-40EF203E673A@mpi-sws.org> <49382030.5020704@network-heretics.com> <2788466ED3E31C418E9ACC5C316615572FFBEF@mou1wnexmb09.vcorp.ad.vrsn.com> <49384BCF.2080600@network-heretics.com>
Comments: In-reply-to Keith Moore <moore@network-heretics.com> message dated "Thu, 04 Dec 2008 16:29:51 -0500."
Date: Fri, 05 Dec 2008 09:35:15 -0500
From: Thomas Narten <narten@us.ibm.com>
X-Mailman-Approved-At: Fri, 05 Dec 2008 07:40:50 -0800
Cc: tae@ietf.org, "Hallam-Baker, Phillip" <pbaker@verisign.com>, ietf@ietf.org, Bryan Ford <brynosaurus@gmail.com>
Subject: Re: [tae] The internet architecture
X-BeenThere: tae@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Architecture Evolution <tae.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/tae>
List-Post: <mailto:tae@ietf.org>
List-Help: <mailto:tae-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tae-bounces@ietf.org
Errors-To: tae-bounces@ietf.org

Keith Moore <moore@network-heretics.com> writes:

> So it's not a question of whether DNS is less reliable than IP (it is),
> or even whether the reliability of DNS + IP is less than that of IP
> alone (it is).  It's a question of whether increasing reliance on DNS by
> trying to get apps and other things to use DNS names exclusively, makes
> those apps and other things less reliable.

No. Your argument seems to be "because relying even more on DNS than
we do today makes things more brittle, BAD, BAD BAD, we cannot go
there."

The more relevant engineering question is whether the benefits of such
an approach outweigh the downsides. Sure there are downsides. But
there are also real potential benefits. Some of them potentially game
changers in terms of addressing real deficiencies in what we have
today. It may well be that having applications be more brittle would
be an acceptable cost for getting a viable multihoming approach that
address the route scalability problem. (All depends on what "more
brittle" really means.) But the only way to answer such questions in a
productive manner is to look pretty closely at a complete
architecture/solution together with experience from real
implementation/usage.

Thomas
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae