Re: [RRG] cache issues in LISP and CONS - it's bad . . .

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

I am correcting some things I wrote about LISP-NERD in an earlier
message - and replying to Eliot Lear and Sheng Jiang.

Hi Eliot,

I apologise for some of the things I have written on the list about
LISP-NERD recently being wrong.  I was writing from my own memory,
which has clearly become garbled - because I wrote that NERD
involved caching and querying in a DNS-like fashion.  I did know
better than this!

Here is new version of the comparison table, with hopefully correct
details for LISP-NERD.

This will look like garbage unless displayed in a fixed width font.

                    LISP-CONS  LISP-NERD  eFIT-APT Ivip    TRRP

Full DB ITRs?       No*        Yes        Default  ITRD    No
                                          Mappers

Caching ITRs?       All*       No         ITR      ITRC    All
                                                   ITFH

Local query         No*                   Default  QSD     No
servers for                               Mappers  QSC
caching ITRs?

Caching ITR must    Yes                   No       No      Yes
drop packets it
has no mapping for?

Distribution of     Pull       ITRs down  Push     Push    Pull
database to         CAR-CDR    load DB &  slow     fast    DNS-like
networks with       global     updates    via      Repli-  global
ITRs etc.?          network    via HTTP   BGP      cator   network
                               from DB             system
                               servers &
                               other ITRs

Incremental                    RRG                 Yes
deployment via                 messages
"anycast ITRs in               264 & 288
the core"?

* Perhaps CONS might be changed to incorporate full DB ITRs to
  which packets would be sent when the caching ITR has no
  mapping information.  See
  http://psg.com/lists/rrg/2007/msg00464.html where Scott Brim,
  co-author of the LISP-CONS ID, wrote: "default mapper :-)".

See my previous message about TRRP having a push system for mapping
changes.

I wrote that only eFIT-APT and Ivip did not drop packets, but this
is true of LISP-NERD too, since all the ITRs have a copy of the full
 database.

In one sense NERD is a "push" model, since the ITRs get all the
mapping data sent to them.  In another sense, it is a "pull" model,
because the updates (and the initial body of mapping data) are only
sent when the ITR requests it.

So mapping data is only as up-to-date according to how recently the
ITR requested and received the latest update, and according to the
timeliness of those updates with respect to when the customer
signalled to the Authority their changed mapping information.


Thanks for your reply, which helped me understand your vision for LISP.

It is difficult to know what number of mappings and what volume of
changes to aim for when devising an ITR-ETR system.

With Ivip I am aiming for something with potentially hundreds of
millions of end-users, mapping single IP addresses or arbitrary
length ranges of them (not just powers of 2).  I am aiming to
support mobility, which means pushing changed mapping as fast as
possible globally.  Ivip's ITRs and mapping data is simpler than
those of the other proposals, because the ITRs make no decisions
about multihoming service restoration - so there is only a single
ETR address for every destination address.  There could be separate,
parallel, Ivip systems with some ITRs handling lots of database
changes for mapping mobile hosts/networks and others for address
space used for more traditional, non-mobile, multihoming and address
portability.


You wrote:

> At least initially, there should be no reason to cache ANYTHING.
> We simply are not yet at an inflection point where we need to.
> This is what the data will show.  If I were a betting man, I might
> put money down on us not needing a cache mechanism for many many
> years.  All of this presumes, of course, that you're updating a
> database about once an hour.  You could break it up in
> smaller increments, but I suspect that's a reasonable operational
> provisioning period, with time to sign and process and all.
> Hence, off-host caching is not an issue with NERD in this case.

So there may be multiple EID Database Authorities and the ITRs need
to request the latest update file, which becomes available about
once an hour.

> Now, suppose I lose my bet.

LISP-NERD is implemented and becomes a great success.  However the
volume of updates and/or the speed with which end-users want their
mapping changes conveyed to the ITRs makes the HTTP-based
ITR-initiated update-file download system impractical.

> Then I would implement CONS or something like it, and bifurcate
> the NERD database into regions, and use LISP for things that are
> outside my region.

I guess you mean full DB download NERD for ranges of addresses which
are most likely to be needed by this ITR, and CONS to request and
cache mapping information for address ranges which are less likely
to be required.

> There is some configuration complexity with this approach that I
> have not fully explored, like how do you decide what region you're
> in, and which databases to use NERD for and to use CONS for.  I
> suspect the answer to these questions lie in having a
> meta-database that is retrieved, but I've not gone much further.

Noel Chiappa discusses regions in another message, to which I will
reply.


Hello Sheng,

Thanks for your response, in which you wrote:

> Well, there may be other branch that seems been forgotten by all
> of us: the future internet architecture, of course, needs a NEW
> mapping system. An efficient, robust mapping system can reduce the
> cache issues a lot, maybe into an acceptable scope.

This means pushing mapping data either to all ITRs (no caching at
all) or at least to some ITRs and/or Query Servers which are located
in many, most or all ISP networks, and so provide much faster and
more reliable responses to queries than is possible with LISP-CONS'
global CAR-CDR network or with TRRP's global DNS-like network.

eFIT-APT proposes doing this, via BGP, which is very slow indeed.  I
am not convinced that BGP consents to this.  Most ITRs are caching
ITRs but the Default Mapper is both a full DB ITR and a query server
for its nearby caching ITRs.

Ivip does this with two types of caching ITR, two types of Query
Server (caching and full DB) and with full DB ITRs.  These can be
deployed much more flexibly than with eFIT-APT.  A minimal system
consists of a single ITRD.  I intend Ivip's database distribution
system to be very fast - a few seconds at most, globally.  This
requires a purpose-built distribution system with high reliability,
and robust security.  I am making progress on this and will write it
up as soon as I can.


> DNS-style mapping system is more than 20 years old and was mainly
> designed for the fixed network. It cannot meet the new
> requirements. If the future internet architecture was established
> on such out-of-time technology, the dead end could be expected.
>
> A new mapping system should at least support: fast updating,
> synchronization if distributed,

I am not sure what this means.

> real-time handover,

There's no way that a global distribution system will work fast
enough for voice continuity when a cell-phone physically connects to
one cell or another, or to one cell in one IP access network from a
cell in another IP access network.  Even if it did, it would be
extremely costly to transmit 12 bytes or so of changed mapping
information to a hundred thousand or more full DB ITRs and Query
Servers every time a lone cell-phone moves a few metres, or its
radio propagation conditions change.

I think that it may be feasible for a mobile device - a cell-phone
or more generally some other device - to establish two connections,
via simultaneous 3G, fibre, WiFi etc. means, and then to use the
global network to have the mapping of its public IP address changed
to the ETR for whichever link it prefers to use.  Still, the cost to
the global mapping distribution network of sending that information
to all full DB ITRs etc. all round the world is high, and I think
there needs to be a charging system per mapping change.  It probably
doesn't need to be a very high charge to make some or all of the
global system financially viable.

> choosing between multiple items, etc.

I don't understand this.

> Furthermore, it must have a business model that supports it. One
> more consideration is that it might support different ID/locator
> separate proposals if we designed it carefully.

I am designing the database distribution (Replicator) system for
Ivip alone, starting with IPv4.  Then I plan to extend it to IPv6.

Anyone who wants to use it or parts of it for any other purpose will
be welcome to do so, but I will be designing only for Ivip.  I think
that if you attempt something as difficult as this with too
demanding, and/or too vague and broad, a set of requirements, the
development time will be too long and/or the result will be bloated
and inelegant.

  - Robin


--
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