Re: [RRG] cache issues in LISP and CONS

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Dan Jen <jenster@CS.UCLA.EDU>

    > Since CONS mapping requests may take a long time to be satisfied, this
    > may result in unacceptable service.

I have done a lot of thinking about optimizations in CONS, in an attempt to
produce a hierarchical distributed pull system with performance which is
close to that of a full-push system. These aren't reflected in the spec yet,
but I imagine some should be in the future.

There's a list of about 10, not all of which will be worth adding; since each
one adds complexity (some more than others), there's a complexity/performance
tradeoff to be considered for each one.

The two main ones (in terms of performance bang) are:

- Caching of EID->RLOC bindings in the CDR hierarchy, which both reduces
resolution delays, as well as decreasing load on aCAR's, for widely used
destinations. This is simple, and makes resolution of widely used
destinations about as fast as a push system.

- 'Piggybacking' the return EID->RLOC binding on the request for the forward
EID->RLOC binding. This one is not universally liked, because it adds a fair
amount of complexity (in part because you have to add authentication to
secure what are effectively unsolicited binding replies; in part because the
caching above means that not all requests actually get to the other end). On
the upside, doing this cuts out *all* of the resolution delay in the reverse
direction in *all* communication pairings, whether to widely used
sources/destinations, or not.


    > Suggestions have been made to route packets on the old topology in the
    > event of ITR cache misses. However, this leads to a major incremental
    > deployment issue -- since LISP adopters will still need to maintain
    > their routes in the old topology, there would be no reduction in the
    > size of the global routing table.

Well, it's not just an incremental issue; either i) we always maintain the
backup routing (in which case we don't get the size reductions, as you point
out), or ii) we don't maintain them into the indefinite future, in which case
the speedup of using the backup routing would not be available in the future.

But since I think we can make the resolution adequately fast, I don't think
there's a problem here.

	Noel

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