re: [RRG] cache issues in LISP and CONS

[Xu Xiaohu <xuxh@huawei.com>]

> -----邮件原件-----
> 发件人: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]
> 发送时间: 2007年10月18日 17:11
> 收件人: rrg@psg.com
> 抄送: jnc@mercury.lcs.mit.edu
> 主题: 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.
Great idea! It looks like BGP damping mechanism, isn't it? 
How to keep the cached mapping, especially those in ITR in real-time? Use
small TTL? This will result in frequent query/reply which is acceptable for
host but not acceptable for router. If the mapping server is a host, is that
practical for forwarding the initial traffic with caching miss? If the
mapping server is a router, can it bear for frequent request/reply pressure?
> 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.
> 
I agree with your opinion.
> 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).
> 
Not just simple, but also no need to consider how to keep the cached mapping
in real-time and no loss of the initial packets with caching miss. Of
course, it depends on a distributed mapping and forwarding mechanism.

Xiaohu XU

> 	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