[rrg] CES & CEE are completely different (graphs)

Robin Whittle <rw@firstpr.com.au> Mon, 01 February 2010 13:36 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 8691D28C180 for <rrg@core3.amsl.com>; Mon, 1 Feb 2010 05:36:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.939
X-Spam-Level:
X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_05=-1.11, 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 zPT6heZ90+pc for <rrg@core3.amsl.com>; Mon, 1 Feb 2010 05:36:16 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 5BBFC28C1AD for <rrg@irtf.org>; Mon, 1 Feb 2010 05:32:59 -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 C519D1759F8; Tue, 2 Feb 2010 00:33:32 +1100 (EST)
Message-ID: <4B66D829.4070502@firstpr.com.au>
Date: Tue, 02 Feb 2010 00:33:29 +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: <20100130184020.9C7AB6BE556@mercury.lcs.mit.edu> <4B6481A0.3020109@joelhalpern.com>
In-Reply-To: <4B6481A0.3020109@joelhalpern.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: [rrg] CES & CEE are completely different (graphs)
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: Mon, 01 Feb 2010 13:36:18 -0000

Short version:    CES architectures are completely different from
                  CEE architectures - and CES is very much superior
                  to CEE.  There are no proposals which combine
                  elements of both.

                  I argue in a companion message:

                    Today's "IP addr. = ID = Loc" naming model
                    should be retained

                  that the current 2-level naming structure - in
                  which the IP address performs the roles of both
                  Identifier and Locator - is superior to the CEE
                  Loc/ID separation approach in which these roles
                  are played by two different objects, in different
                  namespaces.

                  While CEE makes life easy for the routing system,
                  it burdens all hosts with extra work, extra
                  traffic and extra delay just to establish almost
                  any communication session.

                  CES is superior to CEE because it maintains the
                  current naming system.

                  CES is also much easier to adopt than CEE.

                  CES provides immediate full benefits to all
                  adoptors - and provides routing scaling benefits
                  in direct proportion to the level of adoption.

                  CEE only provides substantial benefits to adopters
                  - or significant scaling benefits - after all, or
                  almost all networks have fully adopted it.  This
                  means upgrading essentially every host stack and
                  rewriting essentially every application to use the
                  new CEE Identifier-based method of communication.


Hi Joel,

In "Re: [rrg] Multiple critiques, choice of single proposal, ..."
(msg05846) you wrote:

> If someone wants to add text on Identifier / Locator separation as a
> useful architectural principle, I guess I can't object.  

Do you mean Core-Edge Elimination (CEE) or Core-Edge Separation
(CES)?  Please see this recent message for my concerns about how this
term means different things to different people:

  Terminology: Loc/Id sep., LISP, CEE & CES, namespace
  http://www.ietf.org/mail-archive/web/rrg/current/msg05858.html


> And I consider the CEE / CES debate to be missing the point.

I completely disagree.  These are both capable of solving the scaling
problem, but they are completely different approaches with completely
different costs and methods of achieving their goals.

A CES architecture (LISP, APT, Ivip, TRRP, TIDR or RANGER):

  1 - Maintains the current 2 level naming arrangement - where the
      FQDN is performs the "Text name" role and the Identifier and
      Locator roles are both performed by the IP address.

          Role             Level           Conventional IP & with CES

          Text name  <---- FQDN
          Identifier <---] IP address
          Locator    <---]

  2 - Scalable routing is achieved by creating an "edge" subset of
      the global unicast address range - the remainder of which is
      known as the core.  The "edge" addresses are all covered by
      DFZ-advertised prefixes, but these are few in number, since
      each such prefix (a MAB - Mapped Address Block in Ivip) covers
      a large number of "edge" addresses.  This means the "edge"
      addresses are not much of a burden on the DFZ control plane -
      and do not add much to the numbers of routes to handled by
      the RIBs and FIBs of DFZ routers.

      A new set of network elements - ITRs, ETRs and a mapping
      system - handle all packets addressed to an "edge" address -
      by tunneling them across the DFZ to an ETR, which is always
      on a "core" address.  This is done in a way which supports
      the portability, multihoming, inbound TE and ideally mobility
      needs of end-user networks of all sizes.

      Furthermore, this system enables the edge space to be divided
      much more finely than is possible with the DFZ, since with
      the IPv4 DFZ at least, there is a widely supported convention
      not to propagate prefixes longer than /24.  Ivip and LISP can
      divide "edge" space down to single IPv4 addresses.  Ivip for
      IPv6 manages "edge" space in units of /64.

  3 - Requires no change to host stacks, APIs or applications.
      (Nonetheless, in Ivip the ITR function can optionally be
      implemented in the sending host.)

  4 - Does not affect most internal and DFZ routers, but requires
      the new ITR and ETR functions to be performed in new devices
      and/or existing routers.

  5 - Provides benefits for adoptors immediately - full portability,
      multihoming, inbound TE and ideally mobility benefits to each
      adoptor, irrespective of how many other networks have adopted
      it:

            ^
         B  |*********      Core-Edge Separation (CES)
         e  |*********
         n  |*********
         e  |*********
         f  |*********
         i  |*********
         t  |*********
            |*********
            |*********
            0--------->
              Effort ~= level of adoption

  6 - Provides routing scaling benefits in direct proportion to
      how widely it is adopted, by two mechanisms.  Firstly, more
      end-user networks get the portability, multihoming etc. they
      want/need.  Secondly, they get these benefits without
      significant load on the DFZ.  This will lead to some reduction
      in the number of PI prefixes in the DFZ as current PI-using
      networks adopt the CES architecture.  PI-using networks could
      either convert their PI prefixes to "edge" space and being able
      to use this space more flexibly, in finer slices - or they
      could relinquish their PI space and rent some "edge" space.
      Since "edge" space can be more finely divided, they probably
      don't need as much of it as with PI space, for which the
      finest chunk is /24.

            ^
         B  |        *      Core-Edge Separation (CES)
         e  |       **
         n  |      ***
         e  |     ****
         f  |    *****
         i  |   ******
         t  |  *******
            | ********
            |*********
            0--------->
              Effort ~= level of adoption


A CEE architecture (ILNP, GLI-split, Name Based Sockets, HIP etc.):

  1 - Changes the current naming arrangement so there are separate
      objects, with separate namespaces, for the Identifier and
      Locator roles.  I think most CEE approaches use 3 levels -
      FQDNs for the "Text names", and separate levels to perform
      the Identifier and Locator roles.  In some CEE architectures
      such as ILNP, the lower part of the IPv6 address performs
      the Identifier role and the upper part of performs the
      Locator role.

          Role             Level            Some CEE architectures

                                            such as HIP
          Text name  <---- FQDN
          Identifier <---- HIT
          Locator    <---- IPv6 address


          Role             Level            Some CEE architectures
                                            such as ILNP
          Text name  <---- FQDN
          Identifier <----           IIII IIII } Combined into
          Locator    <---- LLLL LLLL           } one IPv6 address

      I don't yet fully understand Name Based Sockets, but it has a
      naming structure something like this.  In practice, I think
      the Identifier role may be performed by a combination of
      Identifier and Locator, so a single text FQDN can be used
      with "round-robin DNS" to select one of several separate
      hosts, each of which must have a separate Identifier.

          Role             Level            Name Based Sockets?

          Text name  <---] FQDN
          Identifier <---]
          Locator    <---- IPv6 address

  2 - Scalable routing is achieved by applications no longer being
      dependent on stable IP addresses for session continuity.  This
      is because they use an Identifier to determine the host to which
      each communication session is established and maintained.  The
      CEE stack figures out which of potentially multiple Locators
      to use, and Locators can usually be added to and deleted from
      the set of allowable Locators for any one Identifier, as the
      session continues.

      Identifiers are portable.  Multihoming is achieved by the stack
      managing multiple Locators to continue the session if the
      end-user network becomes unreachable by the currently used
      Locator.  Inbound TE is achieved by which Locator is used in
      outgoing packets - since in general the other host will send
      packets back to this host using the Locators this host most
      recently used in outgoing packets.  Mobility is achieved by
      doing all this, and maintaining sessions, despite frequent,
      ad-hoc, changes of Locators.

      When (almost) all a network's hosts are having (almost) all
      their communications occurring with the new CEE arrangement,
      then portability, multihoming and ideally mobility can be
      provided just as well on PA prefixes as on PI.  At this point
      the routing scaling benefits finally occur - all networks can
      do portability multihoming etc.  Those which used to do these
      things via conventional PI space no longer need this PI space.

  3 - Before there can be substantial scaling benefits, all host
      stacks and all applications must be upgraded to use the CEE
      "Loc/ID separation" naming structure.

  4 - Requires no changes to internal of DFZ routers.  There is
      typically a need for a new mapping system by which hosts
      can look up an Identifier and receive the one or more Locators
      that host is using.  (Name Based Sockets uses the existing
      DNS.)

  5 - Provides portability, multihoming, inbound TE and ideally
      mobility benefits to each adoptor, in proportion to how
      many other networks have adopted it.  This is because the
      CEE host and its CEE applications can only provide these
      benefits when communicating with other CEE applications
      in other CEE hosts.  (A good CES system provides these
      benefits to packets sent by all hosts, including those
      in networks without the CES's ITRs.)

      For an adoptor (assuming their hosts communicate, in
      general, with a mix of hosts in all other networks), the
      proportion of communications with the benefits (portability,
      multihoming, TE and ideally mobility) increases linearly
      with the level of adoption.

      However, for most networks, I think it is fair to say that
      they only get real usable benefits when all, or nearly all,
      of their communications are using the new system.  Only then
      can their network be fully portable and multihomed without
      the need for PI space.

            ^
         B  |        *      Core-Edge Elimination (CEE)
         e  |       .*
         n  |      ..*      .  Proportion of communications
         e  |     ...*         with the benefits.
         f  |    ....*
         i  |   .....*      *  Actual total benefits generally
         t  |  ......*         only arise when all, or almost
            | .......*         all, communications have the
            |........*         benefits.
            0--------->
              Effort ~= level of adoption

  6 - Provides routing scaling benefits in two forms:

        A - When most or all networks which have PI space can
            abandon it and use PA space instead.  This is when
            (almost) all of their communications use the new
            system - which is when (almost) all other networks
            have fully upgraded all their host stacks and all
            their applications.

        B - When those without PI space have all, or almost all
            of their communications using the new system, for
            the same reasons as above.

      In both cases, the curve is:

            ^
         B  |        *      Core-Edge Elimination (CEE)
         e  |        *
         n  |        *
         e  |        *
         f  |        *
         i  |        *
         t  |        *
            |        *
            |        *
            0--------->
              Effort ~= level of adoption


CES and CEE are *completely* different ways of solving the routing
scaling problem.

I think everyone agrees that a good CES architecture is easier to
introduce on a voluntary basis than any CEE architecture, since the
adopting networks get full benefits immediately, don't need to alter
their host stacks, or require upgraded versions of their applications.

I think many people believe that the final state of the Internet with
 good CEE architecture is a better than could be achieved with the
best CES architecture.  I think this is because of two interdependent
beliefs:

  1 - The routing system should be kept simple, if there is any
      way hosts can be changed to achieve this.

  2 - The current 2 level IP naming structure - making the IP
      address perform both the Identifier and Locator roles -
      is architecturally flawed and should be fixed to make
      these independent levels, each with a different namespace.
      The practical benefits of this are largely that the
      routing system can be made to scale well, while remaining
      as simple as it is today.  The hosts themselves, with the
      aid of an Identifier -> Locator mapping system, will do
      all the portability, multihoming, TE and mobility work
      themselves.

I disagree with this viewpoint.

I think the routing system should serve the hosts - and that it will
be easier to upgrade the routing system to make it scalable with a
CES architecture, than to upgrade all hosts and all their
applications to implement CEE.

I think the current 2 level IP naming structure is better than the
Loc/ID Separation CEE approach, as explained in the companion message.

Here is my understanding of the arguments for why CEE is the best
long-term arrangement for the Internet:

  1 - Adding new network elements (as are required by CES) is
      inefficient, expensive and contrary to the principle of
      keeping the network simple and elegant, while implementing
      as much of the total functionality of the Net in the hosts.

      Host CPU power is inexpensive.  Host software can be upgraded
      without the need to buy new hardware or establish the
      commercial mechanisms for building and running the ITRs, ETRs
      and mapping system which is required for CES.

  2 - The current IP naming model is fundamentally broken, because
      it makes the one object - the one level of a 2 level system -
      the IP address, play the roles of both Identifier and Locator.

      This is architecturally wrong and it makes it difficult or
      impossible to create a routing system which support large
      numbers of end-user networks with portability, multihoming,
      inbound TE and mobility.

      The right way (as Tony would say) to do it is to create new
      protocols so all hosts communicate with the use of independent
      Identifiers and Locators.


Here are my arguments for why CES is superior to CEE:

  1 - While CES involves adding significant new things to the
      routing system, this is a lot easier than upgrading all
      host stacks rewriting all applications.

      CES early adopters get full benefits, no matter how many
      other networks adopt it.  So a CES is far easier to have
      adopted at all, and then to have fully adopted, than any
      CEE architecture.

      While a CES architecture needs a mapping system, so do most
      CEE architectures.  The CES mapping system is arguably more
      efficient and so can be less costly than that of a CEE
      mapping system because:

         a - The CES mapping system is only used by ITRs - and
             each ITR caches the mapping and will frequently
             use the same mapping to support the communications
             of multiple hosts.

         b - A CES mapping lookup is only required at the start
             of communications sessions where the destination
             address is in the "edge" subset.  Even if CES is
             adopted by all end-user networks which want or need
             portability, multihoming etc. there will still be
             a large number of hosts using PA space.  This includes
             almost all home, SOHO and small commercial customers
             who are doing fine, and will continue to be happy with,
             their one IPv4 (or later an IPv6 /64) of PI space.

             A CEE lookup is needed by both the initiating and
             responding hosts for almost all new communication
             sessions.  The only exceptions are where the
             responding host - such as a DNS server - doesn't care
             if the packet it sends goes to a host which has a
             different Identifier to that used in the request
             packet.

      CEE can't be useful for IPv4, since multihoming a /18
      network would require a /18 of PI space from one ISP and
      another /18 from another ISP.  So it would at least double
      address consumption.

      CEE can't work with hosts behind NAT.  Ideally NAT won't
      be used with IPv6, but this cannot be assured.

      There is another difficulty which I foresee, which I don't
      think has been discussed much - how a CEE copes with a
      host which has one or more Locators on global unicast
      space and one or more locators on one or more private
      address spaces.

      Global unicast Locators can be used to communicate with
      other global unicast Locators - but not private Locators.

      Two hosts with Locators in the same private network space
      can use them to communicate.  This would probably be
      preferred over using the global unicast Locators.  The
      CEE stack and the various protocols between hosts will
      need to cope with the various complications which arise
      from this.

      CEE hosts may need to inform a very large number of other
      hosts they are communicating with if they adopt a new
      Locator and stop using another.  This information also
      needs to be securely uploaded into the DNS and into
      the Identifier -> Locator mapping system.  This is a
      lot of work, particularly for hosts on slow links which
      are subject to congestion and packet loss due to radio
      difficulties.

      IPv6 addresses can have their lower 64 bits frequently
      changed in order to make it difficult for anyone outside
      the network to trace activity, such as to web servers, to
      individual computers - and so by implications to individual
      people.   However, to be able to do this with CEE would also
      involve each such host changing its Identifier as well.
      This could be done, but it involves the creation and deletion
      of state in the public global DNS and Identifier -> Locator
      mapping systems.  This would be onerous and may compromise
      the privacy benefits of the technique.  For CEE architectures
      in which the lower 64 bits of an IP address is the Identifier
      and where Identifiers must be globally unique, then this
      means the randomization of Identifiers can only be within
      a range restricted by whatever range of Identifier space the
      network has been allocated.


  2 - While CEE does involve a simpler network, this benefit is far
      to slight to make up for greater effort hosts must make when
      beginning new sessions.  Please see the companion message:

         Today's "IP addr. = ID = Loc" naming model should be
         retained

      for more details.  This is particularly the case for the
      future, in which most hosts will be running continually
      from small batteries and will generally rely on 3G or similar
      wireless links.


So while both CES and CEE architectures can both, in principle, solve
the routing scaling problem, they do so in completely different ways,
involve completely different adoption hurdles and result in
completely different host protocols in the final system.


> Firstly, many of the solutions and not purely one or the other.  As Noel
> has observed, one can migrate LISP (ostensibly a CES solution) into the
> host.

Whether or not this is done, LISP remains entirely a CES
architecture.  Just because a LISP MN can be its own ETR and ITR
doesn't mean that LISP in any way resembles a CEE system.  The ITR
and ETR functions in such a host would be simple additions to th the
stack.  The IP stack, its API and all applications would remain
unchanged.  The two-layer IP naming structure remains unchanged.

> Architecturally, and in terms of the end state, I think that CEE is a
> much better target.

I hope you will respond to my arguments to the contrary.


> In terms of deployability and related issues, CES techniques tend to
> have a big advantage.

Yes.


> Hence, I have a personal preference for solutions which straddle this
> boundary, 

What are these?  I don't know of any such solutions.



>         rather than seeing utility in arguing about which one we want.

There are huge differences between CEE and CES architectures.


> And I don't the the RG has a clear agreement on this at all.

Not yet.


  - Robin