[ndnSIM] Implementing My Own Cache Management Policy

[Alex Afanasyev]

Hi Kanin,

> On Mar 25, 2015, at 10:13 AM, Kanin Assantachai <kanin at inl.ics.keio.ac.jp> wrote:
> 
> Hello all,
> 
> I am currently using ndnSIM 1.0, and I have been trying to implement my own cache management policy for a while already. However, I have quite a lot of questions to ask as follows.
> 
> 1. Referring to the source code of LRU policy (lru-policy.h), what are  the roles (functions) of codes from line 39 to line 47? I have crossed  check with the code of empty policy (empty-policy.h) and I found that  such codes are not necessary for the case of policy that does not  implement any algorithm.

These are implementation details, related to the use of boost::intrusive container.  With such intrusive containers, necessary pointers for the data structure (for list structure, it would be pointer to previous and the next) need to be stored in the item.  container_hook::type basically defines what exactly the type needed to be stored.  If you want to understand details, I can recommend looking deeper into Boost.Intrusive documentation (http://www.boost.org/doc/libs/1_57_0/doc/html/intrusive.html)

> 2. From line 89 to 96 of the same file (lru-policy.h), the "lookup"  function is implemented there. Why doesn't it handle the case of cache  miss? Based on the code, it seems to me that this case is not handled at  all.

This implementation of CS splits "data plane" (actual data packet lookup) and "control plane" (caching policy) into completely separate elements.  Cache misses are handled by the ContentStore implementation, specifically by Lookup method implemented in model/cs/content-store-impl.h.   Policy is only being notified that there was a successful lookup for this data item, so it can promote it internally (if it is what policy wants to do).

> 3. It seems to me that the "policy_container" in the code serves as a  cache storage (list). I wonder if there are functions I can  use to access specific orders of cached objects in the list at a particular time. Let's say I would like to get the first 5 contents which are stored in the cache storage. How can I possibly do that?

You are right in the sense that it is a list.  The advantage of using boost intrusive container for CS implementation is that this list is just virtual.  policy_container essentially builds up an index, in case of lru policy, it is list-based index where the first item points to the "oldest" cached data packet.

When you say you want to access 5 first data packets, what is the criterion you define order of the items.  If you look into lfu-policy, you can find there that the virtual index is build based on "frequency" of data packet being accessed.  You can define something similar for your policy.

> 4. This question is about the policy I would like to implement. How can  I make nodes automatically send messages about some of the contents of  their stored cache objects to next neighbor nodes? Is it better to  implement this detail in the same cache policy file that I am going to create, or in different files  at different levels? Please kindly provide some suggestions.

I'm not sure I can give a good suggestion here.  It really depends.  Are you planning to send messages every time something is being cached or accessed?  Or is it a periodic function.   In the latter case, it is probably better to do it outside the policy, as part of some "ordinary" application that accesses information in the policy.

> 5. When I simulated the example file "ndn-simple-with-cs-lfu.cc" using the visualizer, I discovered that the request from consumer node still reaches the producer node even after the intermediate router has received the requested content from producer at least once. (The second request from consumer node is sent before the content in the cache of the router expires.) If cache is enabled at the router, why does the later requests (after the first one) still reaches the producer node? Why doesn't the router serve the request with its cache content?

I would say that this example is a little bit misleading and we should really modify it.  The objective for this example is to just demonstrate how hook up different cache policy, and not really the effect of the policy.  In fact, it uses a CBR consumer, which sends requests for unique data items.  This is why you don't see the difference.  You may want to try to use ConsumerZipfMandelbrot (http://ndnsim.net/2.0/applications.html#consumerzipfmandelbrot), which would repeat request for data items.

---
Alex

> 
> Thank you for your responses in advance.
> 
> Kanin Assantachai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20150401/106765dc/attachment.bin>