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/