[ndnSIM] [Fwd: Replacement metric] Done!

Alex Afanasyev alexander.afanasyev at ucla.edu
Wed Sep 4 17:02:39 PDT 2013


Hi Andriana,

I was actually thinking of a slightly different approach to implement, relying purely on multi-policy class. In this way you don't really need to create any lru/lfu/fifo/random modifications, as well as there is no need to modify Add operation in the content store implementation. 

Basically, you can chain "probability" policy and actual policy, while keep using the standard Add operation:

    public ContentStoreImpl< ndnSIM::multi_policy_traits< boost::mpl::vector2< 
	ndnSIM::probability_policy_traits, 
	Policy 
	> 
    > >

(The ultimate result may be different depending on the order of chaining.)

Whenever either of the policies fail to insert item to the cache, Add will fail.  The customized version of content store is only needed to provide a way to configure probability using NS-3 attributes.

Let me know what do you think.

Here is my code:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: probability-policy.h
Type: application/octet-stream
Size: 3683 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20130904/d3d32cd2/attachment.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: content-store-with-probability.cc
Type: application/octet-stream
Size: 3400 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20130904/d3d32cd2/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: content-store-with-probability.h
Type: application/octet-stream
Size: 3183 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20130904/d3d32cd2/attachment-0002.obj>
-------------- next part --------------


For the scenario, you can specify:

  ndnHelper.SetContentStore ("ns3::ndn::cs::Probability2::Lru",
                             "MaxSize", "100",
                             "CacheProbability", "0.5");

(or other policies).

---
Alex

PS
I have a big comment about the randomization in NS-3. Do not use system-provided rand() operation! Major thing is that it will not give you a consistent results for the same simulation run (which is expected from the simulation code), as well as you need to do something with srand.  NS-3 has an extended list of randomization functions that you can use, for example UniformVariable, if you want uniform distribution.  
Also, the way you did randomization is not exactly producing true uniform.  You can read this article http://www.azillionmonkeys.com/qed/random.html, but you can google others as well.

On Sep 4, 2013, at 4:25 PM, ioannoa at scss.tcd.ie wrote:

> Hi Alex,
> 
> I actually think that i solved it! So the scenario was that i had a new
> implementation of the content store - that caches based on a probability
> given through the helper- name content-store-prob-impl.h &
> content-store-prob-impl.cc.
> 
> For that i created the below on files:
> 
> lru-prob-policy.h
> lfu-prob-policy.h
> fifo-prob-policy.h
> random-prob-policy.h
> 
> multi-prob-policy.h
> multi-prob-policy-container.h
> lifetime-stats-prob-policy.h
> 
> content-store-stats-prob.h
> content-store-stats-prob.cc
> 
> cs-prob-tracer.h
> cs-prob-tracer.cc
> 
> so as to be able to collect the results of the metrics the same way as in
> content-store-stats.
> 
> Do not if that is any helpful as further instructions of how the classes
> are linked together. Also, I would be happy to provide them/upload them if
> that is of any interest to have.
> 
> Please let me know if so.
> 
> Kind regards,
> Andriana.
> 
>> Hi Alex,
>> 
>> Indeed i was sth missing.
>> 
>> 
>> Now, i have an other question. I have implemented a content-store-impl
>> class with 2 more functions and also the lru-lfu-fifo-random classes
>> having the same functions included. I want though to use the
>> content-store-with-stats class so as get my results.
>> 
>> How do i link these all together? I tried to modify the multi-policy class
>> to include my functions also but it seems that pit is also using it, so
>> shouldn't do that. Is the case that i need to make new content-store-stats
>> and new multi-policy and new lifetime-stats classes in order to reach my
>> goal?
>> 
>> Thanks in advance.
>> 
>> A.
>> 
>>> Which line it complains exactly? About your "void CacheEntryRemoved
>>> (std::string context, Ptr<const ndn::cs::Entry>" function or something
>>> else?
>>> 
>>> Most likely some include is missing, but I cant yet guess which exactly.
>>> 
>>> ---
>>> Alex
>>> 
>>> On Sep 1, 2013, at 12:21 PM, ioannoa at scss.tcd.ie wrote:
>>> 
>>>> Yeah, i did something like that. But, anyway at the very end i thought
>>>> that since all approaches are gonna be tested under the same patterns,
>>>> it
>>>> wouldn't mind so as to compare them.
>>>> 
>>>> Anyway, one other is that i was simply trying to include the lifetime
>>>> at
>>>> the cs-tracer. A simple simulation example seems to work fine,
>>>> 
>>>> e.g.
>>>> 
>>>> ................................................
>>>> #include <ns3/ndnSIM/utils/tracers/ndn-cs-tracer.h>
>>>> 
>>>> using namespace ns3;
>>>> 
>>>> void
>>>> CacheEntryRemoved (std::string context, Ptr<const ndn::cs::Entry>
>>>> entry,Time lifetime)
>>>> {
>>>> std::cout << entry->GetName () << " " << lifetime.ToDouble (Time::S)
>>>>   << "s" << std::endl;
>>>> }
>>>> 
>>>> int
>>>> main (int argc, char *argv[])
>>>> {
>>>> // setting default parameters for PointToPoint links and channels
>>>> ................................................
>>>> // Read optional command-line parameters (e.g., enable visualizer with
>>>> ./waf --run=<> --visualize
>>>> ................................................
>>>> // Creating nodes
>>>> ................................................
>>>> // Connecting nodes using two links
>>>> ................................................
>>>> // Install NDN stack on all nodes
>>>> ................................................
>>>> ndnHelper.SetContentStore ("ns3::ndn::cs::Stats::Lru", "MaxSize",
>>>> "2");
>>>> // (+)//~
>>>> ndnHelper.InstallAll ();
>>>> Config::Connect
>>>> ("/NodeList/*/$ns3::ndn::cs::Stats::Lru/WillRemoveEntry",
>>>> MakeCallback (CacheEntryRemoved));//(+)
>>>> 
>>>> but when i try to put that into the cs-tracer i get an error of :
>>>> error: ISO C++ forbids declaration of ?type name? with no type
>>>> error: template argument 1 is invalid
>>>> 
>>>> that goes to the string declaration? What is that i am missing here?
>>>> 
>>>> A.
>>>> 
>>>>> Yes. The tracers will do that and it was done semi-intentionally,
>>>>> since
>>>>> some tracers use time period as a base for averaging and doing such
>>>>> averaging could be problematic (or even impossible) in some cases.
>>>>> 
>>>>> The trick that I was using in my simulations is just to set simulation
>>>>> time a little bit longer. Like not 2 seconds exactly, but 2 seconds +
>>>>> 1
>>>>> nanosecond or something.  This way the tracer print event will be
>>>>> properly
>>>>> executed.
>>>>> 
>>>>> Would this work for you?
>>>>> 
>>>>> ---
>>>>> Alex
>>>>> 
>>>>> On Aug 31, 2013, at 6:41 AM, ioannoa at scss.tcd.ie wrote:
>>>>> 
>>>>>> Hey Alex,
>>>>>> 
>>>>>> just a quick question that i just now realized.
>>>>>> 
>>>>>> Is the case in all the tracers that do not actually present the
>>>>>> latest
>>>>>> measurements calculated. e.g. picking a time interval of 1.0 sec for
>>>>>> my
>>>>>> tracers and putting my simulation time also to 1.0 i get no outputs
>>>>>> for
>>>>>> all actually the tracers except the app-delays one.
>>>>>> 
>>>>>> For example I used an experiment of 2.0 seconds with sending up to 10
>>>>>> interest in each sec. so i am getting 20 prints that an interest
>>>>>> reached
>>>>>> the producer application (i print in the OnInterest of the producer
>>>>>> app).
>>>>>> However, the tracer gives me up to 10 when i use a time interval of
>>>>>> 1.0
>>>>>> sec and up to 15 when i use an interval of 0.5 sec. I should get my
>>>>>> 20
>>>>>> but
>>>>>> i suspect that i don't cause the simulation ends first! Is there a
>>>>>> way
>>>>>> i
>>>>>> can actually get the final results too?
>>>>>> 
>>>>>> 
>>>>>> Andriana.
>>>>>> 
>>>>>>> Got it.  I think you can either use directly or with some
>>>>>>> modification
>>>>>>> ContentStoreWithStats (model/cs/content-store-with-stats.h|cc and
>>>>>>> model/cs/custom-policies/lifetime-stats-policy.h)
>>>>>>> 
>>>>>>> Basically, "policy" can be bundled list of several different
>>>>>>> policies
>>>>>>> (I
>>>>>>> called it multi-policy).  In this particular case, I'm bundling
>>>>>>> lifetime-stats-policy with any other policy available (if you're
>>>>>>> working
>>>>>>> on you own, you just need to instantiate it, see .cc file).
>>>>>>> 
>>>>>>> I hope the code is not too confusing :)
>>>>>>> 
>>>>>>> ---
>>>>>>> Alex
>>>>>>> 
>>>>>>> On Aug 30, 2013, at 2:51 PM, ioannoa at scss.tcd.ie wrote:
>>>>>>> 
>>>>>>>> Hi Alex,
>>>>>>>> 
>>>>>>>> no worries. You should have like loads in mind from people sending
>>>>>>>> over.
>>>>>>>> 
>>>>>>>> What i want to count is the number of replacements that happen in
>>>>>>>> each
>>>>>>>> content store of each ndn node. Cache misses and cache hits can be
>>>>>>>> calculated in the content store but content store does not know
>>>>>>>> when
>>>>>>>> a
>>>>>>>> replacement of a content is made in the content store when the Add
>>>>>>>> function is called. The Add function makes use of the insert
>>>>>>>> function
>>>>>>>> of
>>>>>>>> the trie class (lru, lfu, fifo, random ) depending on the policy.
>>>>>>>> So,
>>>>>>>> I
>>>>>>>> would like to calculate that, though not be restricted by one
>>>>>>>> policy
>>>>>>>> only.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> So, sth like this in the lru policy (but ideally not restricted by
>>>>>>>> one
>>>>>>>> policy)
>>>>>>>> 
>>>>>>>> inline bool
>>>>>>>>   insert (typename parent_trie::iterator item)
>>>>>>>>   {
>>>>>>>>     std::cout << "This is Lru class!" << std::endl;
>>>>>>>> 
>>>>>>>>     if (max_size_ != 0 && policy_container::size () >= max_size_)
>>>>>>>>       {
>>>>>>>>         base_.erase (&(*policy_container::begin ()));
>>>>>>>> 
>>>>>>>> -----------------------------------------------------------------------------------
>>>>>>>> ---->>>>          num_of_replacements = num_of_replacements + 1;
>>>>>>>> -----------------------------------------------------------------------------------
>>>>>>>> 
>>>>>>>>       }
>>>>>>>> 
>>>>>>>>     policy_container::push_back (*item);
>>>>>>>>     return true;
>>>>>>>>   }
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Did that make any sense?
>>>>>>>> 
>>>>>>>> Kind regards,
>>>>>>>> Andriana.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Oh sorry. Forgot to reply on that.  I'm actually a little bit
>>>>>>>>> confused
>>>>>>>>> on
>>>>>>>>> what exactly is your objective and what is the problem.
>>>>>>>>> "CacheHits"
>>>>>>>>> and
>>>>>>>>> "CacheMisses" are traces that available for any content store with
>>>>>>>>> any
>>>>>>>>> cache policy and ndn::CsTracer can be used to get the data.  Are
>>>>>>>>> you
>>>>>>>>> referring to something else?
>>>>>>>>> 
>>>>>>>>> ---
>>>>>>>>> Alex
>>>>>>>>> 
>>>>>>>>> On Aug 30, 2013, at 11:20 AM, ioannoa at scss.tcd.ie wrote:
>>>>>>>>> 
>>>>>>>>>> Hello Alex,
>>>>>>>>>> 
>>>>>>>>>> Many thanks for the reply.
>>>>>>>>>> 
>>>>>>>>>> The one seems to work fine. I thought it was for getting the id
>>>>>>>>>> of
>>>>>>>>>> each
>>>>>>>>>> application, so did not count it as a factor.
>>>>>>>>>> 
>>>>>>>>>> I actually posted an other question before this,
>>>>>>>>>> 
>>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>> 
>>>>>>>>>>>> I am trying to implement a replacement metric, similar to the
>>>>>>>>>>>> one
>>>>>>>>>>>> used
>>>>>>>>>>>> for
>>>>>>>>>>>> cache hits and cache misses in content store. My issue is
>>>>>>>>>>>> though
>>>>>>>>>>>> that
>>>>>>>>>>>> replacement counts are not calculated in the content store but
>>>>>>>>>>>> rather
>>>>>>>>>>>> to
>>>>>>>>>>>> each replacement policy used. Would someone advice which way
>>>>>>>>>>>> would
>>>>>>>>>>>> be
>>>>>>>>>>>> proper to try to do so? I have found this post related to:
>>>>>>>>>>>> http://www.lists.cs.ucla.edu/pipermail/ndnsim/2012-December/000007.html
>>>>>>>>>>>> would the creation of a new policy be the way to go?
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> could you please give me a hint for this one too if not much of
>>>>>>>>>> an
>>>>>>>>>> effort?
>>>>>>>>>> 
>>>>>>>>>> Kind regards,
>>>>>>>>>> Andriana.
>>>>>>>>>> 
>>>>>>>>>>> Hi Andriana,
>>>>>>>>>>> 
>>>>>>>>>>> The code looks right, and the whole problem seem to be because
>>>>>>>>>>> of
>>>>>>>>>>> a
>>>>>>>>>>> small
>>>>>>>>>>> problem with "connect" implementation in your tracer.  The
>>>>>>>>>>> producer
>>>>>>>>>>> application is not "aggregated" (in NS-3 terms) on the node,
>>>>>>>>>>> rather
>>>>>>>>>>> than
>>>>>>>>>>> it is installed on a Node as an application.  While it seem the
>>>>>>>>>>> same,
>>>>>>>>>>> it
>>>>>>>>>>> actually requires a slightly different way to connect the trace.
>>>>>>>>>>> The
>>>>>>>>>>> working example is in utils/tracers/ndn-app-delay-tracer.cc:231
>>>>>>>>>>> and
>>>>>>>>>>> in
>>>>>>>>>>> your case ndn-producer-tracer.cc on line 105 could look
>>>>>>>>>>> something
>>>>>>>>>>> like:
>>>>>>>>>>> 
>>>>>>>>>>> Config::ConnectWithoutContext
>>>>>>>>>>> ("/NodeList/"+m_node+"/ApplicationList/*/ServerHits",
>>>>>>>>>>>                             MakeCallback
>>>>>>>>>>> (&ProducerTracer::ServerHits, this));
>>>>>>>>>>> 
>>>>>>>>>>> Can you try it and if it doesn't fix the problem, I'll try to
>>>>>>>>>>> dig
>>>>>>>>>>> more.
>>>>>>>>>>> 
>>>>>>>>>>> ---
>>>>>>>>>>> Alex
>>>>>>>>>>> 
>>>>>>>>>>> On Aug 29, 2013, at 1:55 PM, ioannoa at scss.tcd.ie wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hello all again,
>>>>>>>>>>>> 
>>>>>>>>>>>> further to my previous question I have tried to also implement
>>>>>>>>>>>> a
>>>>>>>>>>>> metric
>>>>>>>>>>>> in
>>>>>>>>>>>> the producer to hold the hits made each time regarding the
>>>>>>>>>>>> interests,
>>>>>>>>>>>> i.e.
>>>>>>>>>>>> how many interests were satisfied by the producer if not from a
>>>>>>>>>>>> content
>>>>>>>>>>>> store of a node along the way.
>>>>>>>>>>>> 
>>>>>>>>>>>> i've tried to use the tracers available and made the included
>>>>>>>>>>>> files.
>>>>>>>>>>>> Unfortunately, even though my file is created, the metric is
>>>>>>>>>>>> always
>>>>>>>>>>>> 0.
>>>>>>>>>>>> Furthermore, having a print in the function updating the
>>>>>>>>>>>> metric,
>>>>>>>>>>>> it
>>>>>>>>>>>> seems
>>>>>>>>>>>> that it is never called! The function is set using the
>>>>>>>>>>>> TracedCallback.
>>>>>>>>>>>> 
>>>>>>>>>>>> Now, i know that the tracer is made for all nodes and not just
>>>>>>>>>>>> specifying
>>>>>>>>>>>> one, but i have tried this for an operation similar to the
>>>>>>>>>>>> cache
>>>>>>>>>>>> misses
>>>>>>>>>>>> or
>>>>>>>>>>>> cache hits at the content store and still did not work, so
>>>>>>>>>>>> can't
>>>>>>>>>>>> see
>>>>>>>>>>>> that
>>>>>>>>>>>> as a problem.
>>>>>>>>>>>> 
>>>>>>>>>>>> I have included the files. If someone has a hint, please let me
>>>>>>>>>>>> know!
>>>>>>>>>>>> 
>>>>>>>>>>>> p.s. the changes in the producer files can be found using //(+)
>>>>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>> finder!
>>>>>>>>>>>> 
>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>> Andriana.
>>>>>>>>>>>> 
>>>>>>>>>>>> ---------------------------- Original Message
>>>>>>>>>>>> ----------------------------
>>>>>>>>>>>> Subject: Replacement metric
>>>>>>>>>>>> From:    ioannoa at scss.tcd.ie
>>>>>>>>>>>> Date:    Thu, August 29, 2013 11:07 am
>>>>>>>>>>>> To:      ndnsim at lists.cs.ucla.edu
>>>>>>>>>>>> --------------------------------------------------------------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> Hello all,
>>>>>>>>>>>> 
>>>>>>>>>>>> I am trying to implement a replacement metric, similar to the
>>>>>>>>>>>> one
>>>>>>>>>>>> used
>>>>>>>>>>>> for
>>>>>>>>>>>> cache hits and cache misses in content store. My issue is
>>>>>>>>>>>> though
>>>>>>>>>>>> that
>>>>>>>>>>>> replacement counts are not calculated in the content store but
>>>>>>>>>>>> rather
>>>>>>>>>>>> to
>>>>>>>>>>>> each replacement policy used. Would someone advice which way
>>>>>>>>>>>> would
>>>>>>>>>>>> be
>>>>>>>>>>>> proper to try to do so? I have found this post related to:
>>>>>>>>>>>> http://www.lists.cs.ucla.edu/pipermail/ndnsim/2012-December/000007.html
>>>>>>>>>>>> would the creation of a new policy be the way to go?
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks in advance.
>>>>>>>>>>>> 
>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>> Andriana.<ndn-producer-tracer.cc><ndn-producer-tracer.h><ndn-producer.cc><ndn-producer.h>_______________________________________________
>>>>>>>>>>>> ndnSIM mailing list
>>>>>>>>>>>> ndnSIM at lists.cs.ucla.edu
>>>>>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 



More information about the ndnSIM mailing list