[rrg] Arguments in favour of Core-Edge Elimination vs. Separation?
Robin Whittle <rw@firstpr.com.au> Fri, 22 January 2010 01:52 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 A452A3A6858 for <rrg@core3.amsl.com>; Thu, 21 Jan 2010 17:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.546
X-Spam-Level:
X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 NXBQkkCUz0VR for <rrg@core3.amsl.com>; Thu, 21 Jan 2010 17:52:49 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 27A923A6848 for <rrg@irtf.org>; Thu, 21 Jan 2010 17:52:49 -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 293C6175C90; Fri, 22 Jan 2010 12:52:44 +1100 (EST)
Message-ID: <4B5904EF.5060208@firstpr.com.au>
Date: Fri, 22 Jan 2010 12:52:47 +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>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?
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: Fri, 22 Jan 2010 01:52:50 -0000
Tony - as far as I know, you are opposed to CES (Core-Edge Separation) and in favour of CEE (Core-Edge Elimination). 5 or 6 full proposals are CEE and only 4 are CES (LISP, Ivip, TIDR and RANGER) - so it seems that many active RRG folks fully support CEE in favor of CES. The "simple network, sophisticated hosts" paradigm works well in many respects and I understand there is a perception of elegance in CEE - which extends this principle further to get hosts to do more routing and addressing work so the routing system can remain simple. Introduction of CEE would involve new host protocols and usually new application code and APIs in order that hosts and networks can have multihoming TE, portability (of their identifiers) and probably mobility - while operating entirely from potentially unstable PA addresses obtained from their one or more ISPs. (In some schemes, the ISP's address space only forms the more significant bits of the host's PI address.) Routing scalability is achieved by way of the DFZ routers only having to cope with the prefixes of ISPs - not of any end-user networks. I hope CEE supporters will argue their case explicitly. My support for CES is stated fully in section 4.1 of the Ivip-arch ID. I think CEE's attraction is based on an over-simplified notion of the Internet: a routing system with hosts neatly arranged around the edge. If I thought this was the reality, I would agree that CEE is the optimal approach - though I would still have no idea how we could change to CEE on a voluntary basis from the current arrangement. However, the Internet's routing system is big and has traffic costs, delays and risks of lost packets. Furthermore, an increasing number of hosts are on slow, less-reliable, and sometimes expensive wireless links. These problems are fundamental - most wireless links will never be like fibre or DSL because the spectrum is shared, the base-stations and mobile devices are interfering with each other, the timeslots take time come around and because upstream capacity usually has to be reserved in advance. An increasing number of hosts have computational constraints due to being hand-held devices with very limited battery power. This is no problem for simple protocols and caching a few things, but if cryptographic work is required in the CEE protocols, then I think it is more of a problem. I believe the optimal arrangement for the Internet is not the CEE approach of requiring *all* hosts to take on more responsibilities for routing and addressing - which generally involves more state, more computation, delays in initiating contact with other hosts and the sending and receiving more and/or longer packets. It also involves a lot of extra work, packets and therefore delays whenever the host gets a different (physical, "locator") address. This can happen frequently with wireless mobile devices, even when they are stationary. These things might be tolerable and desirable if the Internet's core had no delays or other costs, and if all hosts were on fast, inexpensive links and had plenty of CPU power. But CEE generally causes more delays even with hosts on fast links, due to the extra work they need to do to be sure of the identity of the other hosts they are communicating with and the fact that the lookups and management packets frequently encounter delays in the core, due to the size of the Earth and the speed of light in SiO2. I think CEE would cause unacceptable performance problems and higher costs for wireless mobile devices - since extra management traffic has to flow back and forth along this slow and perhaps unreliable link, frequently before real host-to-host communications begin. IPv6 makes such management packets longer still. Some systems CEE architectures involve adding extra stuff to traffic packets, at least for some packets. This is further burden on devices relying on wireless links. In the future, I think we should expect that most hosts are going to be wireless mobile devices. I support the CES approach of retaining the existing host protocols and instead adding things to the network (ITRs, ETRs, mapping system etc.) to solve the scaling problem and provide mobility. My arguments for Core-Edge Separation are in section 4.1: http://tools.ietf.org/html/draft-whittle-ivip-arch#section-4.1 Tony - the reason I think you support CEE is this message from mid-2008: http://lists.arin.net/pipermail/arin-ppml/2008-June/010988.html Please, please, please go read GSE. You may not like it, you may not agree with it, but until you grok it, you haven't seen a big chunk of the solution space. and because I don't recall you writing anything in support of LISP, Ivip or any other CES proposal. In the next few weeks I hope to analyse each of the CEE proposals in detail, to determine to what extent my critique about extra delays, extra packets etc. applies to them. - Robin
- [rrg] Arguments in favour of Core-Edge Eliminatio… Robin Whittle
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Patrick Frejborg
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Xu Xiaohu
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Patrick Frejborg
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Noel Chiappa
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Brian E Carpenter
- [rrg] Ivip exemplifies Noel's support for "Advent… Robin Whittle
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Robin Whittle
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Patrick Frejborg
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Noel Chiappa
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Scott Brim
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Noel Chiappa
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Scott Brim
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Noel Chiappa
- Re: [rrg] Arguments in favour of Core-Edge Elimin… heinerhummel
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Patrick Frejborg
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Robin Whittle
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Scott Brim
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Patrick Frejborg
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Robin Whittle
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Noel Chiappa
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Noel Chiappa
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Fred Baker
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Patrick Frejborg
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Patrick Frejborg
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Robin Whittle
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Noel Chiappa
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Patrick Frejborg
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Noel Chiappa
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Brian E Carpenter
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Noel Chiappa
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Brian E Carpenter
- Re: [rrg] Arguments in favour of Core-Edge Elimin… Robin Whittle