[RRG] Mapping model discussion - push, pull, hybrids and notify

[Robin Whittle <rw@firstpr.com.au>]

As noted in a recent message ("Agenda") there is an item "Mapping
Model Discussion" for discussion on Tuesday:

  http://www3.tools.ietf.org/group/irtf/trac/wiki/RRGagendaPhily

I am not sure what this discussion will entail.  Perhaps it will be
theoretical discussion of different ways of getting the mapping data
where it is needed, without pushing it everywhere - whilst avoiding
discussion of current proposals.

In case it is a discussion about push, pull, hybrids etc. here is
some stuff which might be of interest - my analysis of the mapping
distribution aspects of the major proposals.

  - Robin


LISP-NERD  Pure push.

   The entire mapping database is pushed, relatively slowly, to
   every ITR.  ITRs do this by initiating downloads of files from
   some servers, such as by using HTTP.

   (NERD also contemplates a hybrid of push and pull, where some
    likely to be frequently used parts of the mapping database
    are downloaded - pushed - and others are not.  This means that
    for some EIDs the ITR is a full database ITR and for others
    it is a caching ITR, relying on some query server system, such
    as ALT or CONS.  But if at least some ITRs can get the full
    database, why not make them, or servers near them into query
    servers, so nearby partly caching ITRs can query them?  See:
    http://psg.com/lists/rrg/2008/msg00176.html.)

   Major strengths:  No delay of packets.

   Major critique:   Lots of mapping data to push and store at
                     every ITR.  Also NERD's "push" system
                     is not very fast or efficient.  For instance
                     unless there is some other elaboration,
                     a hundred ITRs in one are of the Net will each
                     be doing independent downloads, rather than
                     using some nearby staging point where the data
                     is fanned out, or getting the data one from
                     another.



LISP-ALT   Pure pull.

   All ITRs are caching ITRs and use a global network to send
   queries (typically in the form of traffic packets which will
   be delivered to the correct ETR) to the authoritative query
   servers, which are typically ETRs.

   Major strengths: Can scale to any number of EIDs without any
                    extra burden on ITRs.

   Major critiques: Initial packets will frequently be delayed due
                    to the time it takes to look up the mapping or
                    to deliver the packet (much the same thing)
                    over the global ALT network.  Furthermore,
                    unless there is some elaboration, the path
                    through the ALT network's routers will not
                    be optimised for geography, and could involve
                    many long trips back and forth around the
                    world.


TRRP      Pure pull - but with two incomplete "notify" techniques

   All ITRs are caching ITRs and use DNS to look up mapping.  So
   this is another global query server system.

   The two approaches to pushing an alert about updated mapping
   are incomplete.  One involves sending messages to the querier,
   but the querier may not be reachable, especially if the query
   went via a caching DNS server.  The other involves the ITR
   signalling unreachability of the destination, which may prompt
   the ITR to do a fresh mapping request.  Also, there is an initial
   packet delivery system (waypoint routers) which may not scale
   well.  See: messages 450, 475 etc.

   Major strengths: Like ALT, can cope with arbitrary numbers of
                    EIDs/micronets without any extra burden on
                    ITRs.

   Major critiques: Slowness of query server network due to global
                    nature and need for two lookups, at least.
                    Resolvable by converting the whole DNS server
                    system into locally replicated server farms
                    which answer the query directly.  This somewhat
                    resembles the hybrid push-pull nature of APT
                    or Ivip.  See message 497.


APT   Hybrid push-pull (slow push) with local notify

   Full mapping database (for the APT island) pushed to all Default
   Mappers (DMs) which are full database ITRs and full database
   query servers.  Push is relatively slow, via BGP flooding.

   The rest of the ITRs are caching ITRs and get their mapping
   quickly from a DM, by sending a traffic packet to the DM,
   which also tunnels it to the correct ETR.  DM can notify
   ITRs of changed mapping.

   Major strengths: Most ITRs can be cheaper caching ITRs, but
                    the get mapping quickly and reliably, without
                    delaying packet delivery, thanks to the local
                    nature of the query servers they rely on.

                    Greatly reduces the number of places the full
                    mapping database needs to be pushed to, compared
                    to NERD's full push.

  Major critiques:  Since there is no unified global mapping system
                    the APT system starts off as individual islands,
                    which can't support end-user networks properly
                    if those networks use longer prefixes than the
                    /24 which is the practical limit in today's
                    IPv4 network.  See messages 472, 485-87 etc.
                    (To be continued.)

                    Slow rate of push compared to NERD or Ivip.


Ivip   Hybrid push-pull (fast push) with local notify.

   Fast push to full database ITRs and query servers, located
   wherever operators want them.  Unified but decentralised
   global push system enables charging per mapping change, which
   is difficult or impossible to achieve with BGP, and could be
   tricky to implement with APT.

   Beyond the full database ITRs and query servers, ITRs are caching
    - including caching ITRs in sending hosts.  ITRs query the local
   full database query servers directly, or via one or more levels
   of caching query server.  Query servers notify recent queriers of
   mapping changes, using UDP packets, and expect acknowledgement.
   Notify message carries the new mapping information - it is not
   just cache invalidation.  Notify is secured by using the nonce
   from the initial query.

   Major benefits:  Like APT, but with greater flexibility,
                    enables operators to choose how far to push
                    the full database into their networks.  Good
                    support for micronets down to /32.

                    The fast (~5 second) nature of the push system
                    means the mapping can be simple, only a single
                    ETR address.  End-users do their own multihoming
                    monitoring and make their own decisions about
                    service restoration, so the system is modular
                    rather than monolithic.  Also, as a result of
                    the single ETR mapping data, less mapping to
                    store and simpler functionality for ITRs and
                    ETRs, which don't need to do reachability stuff.

                    Fast push also enables the system to be used
                    for IPv4 and IPv6 mobility with generally
                    optimal path lengths, no upgrades for
                    correspondent hosts and few for the mobile
                    hosts.  See Ivip-summary.pdf for full list
                    of benefits of fast push.


   Major critiques: No explicit TE function in the ITR, so user
                    has to do it by splitting traffic over
                    multiple micronets, and mapping each micronet
                    to different ETRs.

                    Most folks seem to think fast push is difficult
                    or impossible, and are wary of any system which
                    pushes the full database anywhere.  But it
                    looks feasible to me - and there have been
                    no detailed critiques of the db-fast-push ID at:
                    http://www.firstpr.com.au/ip/ivip/


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg