[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: [RRG] cache issues in LISP and CONS
> 发件人: firstname.lastname@example.org [mailto:email@example.com] 代表 Noel Chiappa
> 发送时间: 2007年10月18日 5:02
> 收件人: firstname.lastname@example.org
> 抄送: email@example.com
> 主题: 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,
> > may result in unacceptable service.
> I have done a lot of thinking about optimizations in CONS, in an attempt
> 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
> 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
> one adds complexity (some more than others), there's a
> 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?
> - 'Piggybacking' the return EID->RLOC binding on the request for the
> EID->RLOC binding. This one is not universally liked, because it adds a
> amount of complexity (in part because you have to add authentication to
> secure what are effectively unsolicited binding replies; in part because
> caching above means that not all requests actually get to the other end).
> the upside, doing this cuts out *all* of the resolution delay in the
> 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
> > event of ITR cache misses. However, this leads to a major
> > 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
> out), or ii) we don't maintain them into the indefinite future, in which
> the speedup of using the backup routing would not be available in the
> But since I think we can make the resolution adequately fast, I don't
> there's a problem here.
> to unsubscribe send a message to firstname.lastname@example.org 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 email@example.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