Re: [rrg] Critique - ILNP and the other 5 core-edge elimination proposals
Robin Whittle <rw@firstpr.com.au> Wed, 06 January 2010 04:39 UTC
Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCADB3A6873 for <rrg@core3.amsl.com>; Tue, 5 Jan 2010 20:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level:
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_RAND_LETTRS4=0.799]
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 GBP9-RVAoFcz for <rrg@core3.amsl.com>; Tue, 5 Jan 2010 20:39:40 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 2723C3A6867 for <rrg@irtf.org>; Tue, 5 Jan 2010 20:39:40 -0800 (PST)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id AE909175D3B; Wed, 6 Jan 2010 15:39:37 +1100 (EST)
Message-ID: <4B44140B.7060504@firstpr.com.au>
Date: Wed, 06 Jan 2010 15:39:39 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <4B4348D5.70201@joelhalpern.com>
In-Reply-To: <4B4348D5.70201@joelhalpern.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [rrg] Critique - ILNP and the other 5 core-edge elimination proposals
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2010 04:39:42 -0000
Hi Joel, Here are two critiques which I think apply to ILNP and the other 5 proposals which I believe are core-edge elimination, schemes as I wrote: http://www.ietf.org/mail-archive/web/rrg/current/msg05562.html GLI-Split hIPv4 Name-Based Sockets Name overlay (NOL) service for scalable Internet routing RANGI - Robin 1 - Core-edge elimination schemes are impossible to introduce widely enough on a voluntary basis to solve the routing scaling problem. Section 4.1 of this paper mentions this, in terms of the core-edge elimination schemes involving changes in edge networks in order to reduce costs in core/transit networks: Towards a Future Internet Architecture: Arguments for Separating Edges from Transit Core Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf There is no direct incentive for edge networks to make this investment. Also, the benefits only flow once all edge networks fully adopt the new system. Core-edge elimination involves new host functionality - in stacks and often in applications. This is at odds with the constraints due to the need for widespread voluntary adoption: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ because the upgraded hosts can only achieve scalable multihoming, TE, portability etc. when communicating with the initially very small subset of other hosts which are also upgraded. These benefits are too small to enable the abandonment of existing unscalable portability, multihoming etc. arrangements and too small to motivate many people to adopt the new system. This list of constraints has been discussed on the RRG and has received considerable support. No-one has suggested this list miss-states the real constraints which exist, or that there is another way of introducing a solution than by widespread voluntary adoption. 2 - Core-edge elimination schemes place more routing and addressing responsibilities on hosts. Its OK for a scalable routing architecture to make this an option, but core-edge elimination schemes enforce it on all hosts. This means all hosts must be more complex and engage in extra communications in order to implement their new responsibilities. This can be a problem even for well-connected hosts, where looking up mapping, engaging in cryptographic exchanges etc. are necessary before user data can be transacted, involving extra delays, state, CPU effort etc. It is completely unworkable for mobile hosts which typically have low CPU capabilities and most importantly are connected via wireless links which are slow, unreliable and expensive. I wrote about this on the RRG and then made a web page: http://www.ietf.org/mail-archive/web/rrg/current/msg05471.html http://www.firstpr.com.au/ip/ivip/RRG-2009/host-responsibilities/
- [rrg] Critique Joel M. Halpern
- Re: [rrg] Critique - ILNP and the other 5 core-ed… Robin Whittle
- Re: [rrg] Critique - ILNP and the other 5 core-ed… Shane Amante