re: [RRG] cache issues in LISP and CONS

[Xu Xiaohu <xuxh@huawei.com>]

> -----邮件原件-----
> 发件人: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 代表 Noel Chiappa
> 发送时间: 2007年10月18日 5:02
> 收件人: rrg@psg.com
> 抄送: jnc@mercury.lcs.mit.edu
> 主题: Re: [RRG] cache issues in LISP and CONS
> 
>     > 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.
> 
How to determine the widely used destination when taking the P2P traffic,
which consumes more than 60~70% of the total bandwidth, into account?

Once caching is deployed in the CDR hierarchy, does the ITR still need to
use cache mechanism?

Xiaohu Xu

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


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