re: [RRG] cache issues in LISP and CONS

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

    > 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