RE: [RRG] cache issues in LISP and CONS

[<jarno.rajahalme@nsn.com>]

Have you looked at the Behive replication framework? The authors have
demonstartrated it's use as DNS replacement (CoDoNS). It does proactive
popularity based replication, and allows you to meet arbitrary average
lookup latencies (O(1)). Based on the CoDoNS paper
(http://www.cs.cornell.edu/people/egs/beehive/codons-sigcomm04/index.htm
l) the system outperforms DNS on all metrics.

The Behive overview is on the same paper:

http://www.cs.cornell.edu/people/egs/beehive/codons-sigcomm04/node12.htm
l

I have't tried to apply this to the mapping problem between EIDs and
RLOCs, but since Behive is prefix based, so there might be a beautiful
application of it to EID that have some hierarchy in them (=prefix).

Further I believe the mapping system should be such that it stays within
the core, i.e. all the mappings are resolvable within the BGP routable
core, so that resolving the mappings does not depend on any such
mappings itself!

	Jarno  

>-----Original Message-----
>From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf 
>Of ext Noel Chiappa
>Sent: 18 October, 2007 18:11
>To: rrg@psg.com
>Cc: jnc@mercury.lcs.mit.edu
>Subject: re: [RRG] cache issues in LISP and CONS
>
>    > From: Xu Xiaohu <xuxh@huawei.com>
>
>    > How to determine the widely used destination
>
>I spent a lot of time thinking about that, and finally came up 
>with what I think is a very efficient (in terms of overhead), 
>and extremely effective (in terms of correctly identifying 
>which mappings are widely used) system for deciding which 
>entries to cache in the CDRs.
>
>Basically, it works by starting with the actual mappings in 
>the aCARs; those entries have to always exist anyway, so it is 
>just an extra field in those entries, which gets incremented 
>any time the mapping is requested. When the aCARs notice a lot 
>of requests for a particular mapping, they suggest to their 
>parent CDR(s) that they cache that mapping. The same process 
>then repeats at each CDR level.
>
>We will have to tune it a bit, and adjust the constants (i.e. 
>how many requests are enough to trigger the upward cache) but 
>the basic mechanism is very good.
>
>
>    > when taking the P2P traffic, which consumes more than 
>60~70% of the
>    > total bandwidth, into account?
>
>Bandwidth is not necessarily the same as number of 
>connections, and the need for a mapping only exists when a 
>connection is opened. Since my understanding is that most P2P 
>traffic is for large media files, I suspect that they account 
>for a smaller percentage of connection openings. Also, since 
>they are for large files, if they take a few extra 
>tens/hundreds of milliseconds to start, I think that is 
>probably acceptable.
>
>Also, the second optimization I mentioned (having the 
>EID->RLOC mapping for the source carried along with the 
>request for the EID->RLOC mapping for the
>destination) will help P2P connections too (since it helps 
>*every* connection).
>
>Of course, if we were designing the entire network from 
>scratch, we would probably have the mapping system return both 
>the EID and RLOC, or something like that; it doesn't make 
>sense to have two separate resolution cycles.
>However, we have to live with what it already out there, which 
>means this resolution step has to be a separate system.
>
>
>    > Once caching is deployed in the CDR hierarchy, does the 
>ITR still need
>    > to use cache mechanism?
>
>I would say yes, but remember, a cache is just a way to 
>increase performance.
>So, if you can get 'good enough' performace without the cache, 
>you don't have to have it.
>
>What would be the benefit to not having the ITR cache entries? 
>Making them simpler? The disadvantage is that every connection 
>would be slower to open (the ITR would have to talk to the rCAR).
>
>	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