[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