[ndnSIM] Inconsistent number of sent packets

Sat Apr 20 05:09:31 PDT 2013

Hi Alex,

Yes. In my scenario, the network configuration is the same as the example.
I just applied my forwarding strategy into it making part of interests sent
from face 0 and 1 simultaneously. So there is traffic on both interface 0
and 1.

Thanks for your explanation about L3RateTracer. Just now I also found that
the more I print logging information (including self-written logging
information), the less "Tx Packets" in visualizer or "PacketRaw" of
"OutInterests" in L3RateTracer is. As you said before, the missing
Interests are from the Interest retransmission which is also deemed as new
Interests in "Cbr". So is there a way to decrease the Interest
retransmission (at best to 0) from the time viewpoint?

Another question is about the value of "Packets" column in rate-trace.txt.
Why its value is not an integer? It refers to the layer 1 (or layer 2)
packets which is not a ndn packet?

Thanks for your point-out for "DidSendOutInterest". I added
m_outInterests() to my CustomStrategy::DidSendOutInterest. the OutInterests
value works well.

Regards,
huyao

2013/4/20 Alex Afanasyev <alexander.afanasyev at ucla.edu>

> Hi huyao,
>
> I run the grid scenario in visualizer with displaying interface statistics
> and i got exactly 2000 for interface 0 and 0 for interface 1:
>
>
> Did you make any other modification to the scenario?  I really wonder how
> can you get any traffic on interface 1 in this scenario, as there should
> not be anything at all...
>
> About L3RateTracer. The line "20 Node0 2 dev=local(2) InInterests" tells
> you rate/number of interests that were received by NDN stack from the
> application face.  From the application point of view, these are outgoing
> interests, but from the NDN stack point of view (since L3 tracer presents
> NDN stack point of view), these are incoming.   I still don't really
> understand why do you have traffic on both interfaces... I suppose this is
> something that your custom forwarding strategy is doing?
>
> Btw. If in your strategy you're not using "TrySendOutInterest" method of
> the base class, then to have proper L3 logging you need to
> call DidSendOutInterest after interest were successfully sent out.  Right
> now I see inconsistencies in numbers reported by L3RateTracer: line "20
> Node0 0 dev[0]=net(0,0-1) OutInterests 0 0 0 0" should be non-zero.
>
> ---
> Alex
>
> On Apr 19, 2013, at 8:16 AM, yao hu <huyao0107 at gmail.com> wrote:
>
> Hi Alex,
>
> "Tx Packets" is from the "interface statistics" (right click the node from
> the ns3 visualizer) of the node0 which is the data requester in this grid
> scenario. Just now I tried it again by setting interest frequency as 100
> (for 20 seconds), still the "Tx Packets" is 1805 (interface 0) and 22
> (interface 1). The missing "Tx Packets" (around 200) are from the interest
> retransmission? I also used the L3RateTracer following your instruction (as
> follows).  The "PacketRaw" column of
> 20 Node0 2 dev=local(2) InInterests
> refers the number of outgoing interest packets? Then what is the
> difference between this "2000" and that "1805"?
>
> Thanks very much for your time!
>
> Time Node FaceId FaceDescr Type Packets Kilobytes PacketRaw KilobytesRaw
> 20 Node0 0 dev[0]=net(0,0-1) InInterests 0 0 0 0
> 20 Node0 0 dev[0]=net(0,0-1) OutInterests 0 0 0 0
> 20 Node0 0 dev[0]=net(0,0-1) DropInterests 0 0 0 0
> 20 Node0 0 dev[0]=net(0,0-1) InNacks 0 0 0 0
> 20 Node0 0 dev[0]=net(0,0-1) OutNacks 0 0 0 0
> 20 Node0 0 dev[0]=net(0,0-1) DropNacks 0 0 0 0
> 20 Node0 0 dev[0]=net(0,0-1) InData 71.72 74.0581 1793 1851.45
> 20 Node0 0 dev[0]=net(0,0-1) OutData 0 0 0 0
> 20 Node0 0 dev[0]=net(0,0-1) DropData 0.12 0.12375 3 3.09375
> 20 Node0 1 dev[0]=net(1,0-3) InInterests 0.04 0.00105469 1 0.0263672
> 20 Node0 1 dev[0]=net(1,0-3) OutInterests 0 0 0 0
> 20 Node0 1 dev[0]=net(1,0-3) DropInterests 0.04 0.00105469 1 0.0263672
> 20 Node0 1 dev[0]=net(1,0-3) InNacks 0 0 0 0
> 20 Node0 1 dev[0]=net(1,0-3) OutNacks 0 0 0 0
> 20 Node0 1 dev[0]=net(1,0-3) DropNacks 0 0 0 0
> 20 Node0 1 dev[0]=net(1,0-3) InData 0.84 0.865859 21 21.6465
> 20 Node0 1 dev[0]=net(1,0-3) OutData 0.04 0.0412891 1 1.03223
> 20 Node0 1 dev[0]=net(1,0-3) DropData 0.72 0.742109 18 18.5527
> 20 Node0 2 dev=local(2) InInterests 80 2.12891 2000 53.2227
> 20 Node0 2 dev=local(2) OutInterests 0 0 0 0
> 20 Node0 2 dev=local(2) DropInterests 0.2 0.00507813 5 0.126953
> 20 Node0 2 dev=local(2) InNacks 0 0 0 0
> 20 Node0 2 dev=local(2) OutNacks 0 0 0 0
> 20 Node0 2 dev=local(2) DropNacks 0 0 0 0
> 20 Node0 2 dev=local(2) InData 0 0 0 0
> 20 Node0 2 dev=local(2) OutData 71.72 74.0581 1793 1851.45
> 20 Node0 2 dev=local(2) DropData 0 0 0 0
>
>
> 2013/4/19 Alex Afanasyev <alexander.afanasyev at ucla.edu>
>
>> Hi huyao,
>>
>> Hmm.  I just run ndn-grid scenario with frequency 10, 100, and 1000 and
>> in all of the cases I see that the consumer send out exactly the
>> theoretical amount of interests within 20 seconds (200, 2000, and 20000),
>> though the same consumer has received different number of Data packets back
>> due to buffer overflows (199, 1989, 2342).
>>
>> How exactly did you measure number of Interests and I'm not very sure
>> what is "Tx Packets" you were referring to?  I obtained my data
>> using ndn::L3RateTracer.  I put the following before Simulation::Run() in
>> ndn-grid scenario (assuming the total simulation time is 20 seconds):
>>
>> boost::tuple< boost::shared_ptr<std::ostream>,
>> std::list<Ptr<ndn::L3RateTracer> > >
>>     rateTracers = ndn::L3RateTracer::InstallAll ("rate-trace.txt",
>> Seconds (19.99999999));
>>
>> (don't forget to include the header file:
>> #include <ns3/ndnSIM/utils/tracers/ndn-l3-rate-tracer.h>
>> )
>>
>> ---
>> Alex
>>
>> On Apr 18, 2013, at 7:07 AM, yao hu <huyao0107 at gmail.com> wrote:
>>
>> Hi Alex,
>>
>> The scenario I tested in is just the 9-node grid topology. I think maybe
>> it has something wrong with my modified algorithm, since it shows no
>> problem with a certain interest frequency, while with larger interest
>> frequency (generally speaking) , the missing interest packets become
>> obvious. I will check it soon. Thanks for your reply about routingCost. I
>> see. :)
>>
>> Regards,
>> huyao
>>
>>
>>
>> 2013/4/18 Alex Afanasyev <alexander.afanasyev at ucla.edu>
>>
>>> Can you send out scenario (or link to scenario), so I can try to debug
>>> the problem on my machine?
>>>
>>> routingCost is basically an aggregated cost for the specific path.  If
>>> you're using globalRoutingController, it sums up all the specified metrics
>>> on the path.  For example, if you have this topology
>>>
>>> node1 ------ node2 ------- node3 ------- node4
>>>
>>> and all metrics for each link is 10, then routing cost on node1 to
>>> forward towards node4 using the only available face would be 30.
>>>
>>> If you are using "EnableDefaultRoute" in ndn::StackHelper, then this
>>> value doesn't really mean anything and suggests only that this "default" is
>>> the least preferred option to forward interests.
>>>
>>> ---
>>> Alex
>>>
>>> On Apr 17, 2013, at 8:36 AM, yao hu <huyao0107 at gmail.com> wrote:
>>>
>>> Hi Alex,
>>>
>>> I did not specify any randomization using Randomize parameter. I am not
>>> sure whether all the interests are consumed at the first attempt, but if
>>> that is a reason, the retransmitted Interest packets are not counted into
>>> "Tx Packets"? Besides, I am not sure about the meaning of routingCost
>>> column (2147483647) in FIB. Does it has something different from the
>>> 'metric' which affects the forwarding strategy to select the BestRoute?
>>> Could I specify it somewhere?
>>>
>>> Sorry for many questions. Thanks very much!
>>>
>>> Regards,
>>> huyao
>>>
>>>
>>>
>>> 2013/4/17 Alex Afanasyev <alexander.afanasyev at ucla.edu>
>>>
>>>> Hi huyao,
>>>>
>>>> Did you specify any randomization for inter-interest gap using
>>>> Randomize parameter (uniform, exponential)?  Though, by default there is no
>>>> randomization.
>>>>
>>>> Btw. Do all your interest are getting satisfied from the first attempt?
>>>>  If not, the difference can come from the interest retransmission, since
>>>> those that needs to be retransmitted are sharing the same "cbr" constraints
>>>> as new interests.
>>>>
>>>> ---
>>>> Alex
>>>>
>>>> On Apr 16, 2013, at 8:32 AM, yao hu <huyao0107 at gmail.com> wrote:
>>>>
>>>> > Hi Alex,
>>>> >
>>>> > Just now, in order to verify my modification I used CustomerCbr to
>>>> produce a certain number of Interest from a specific consumer, however, I
>>>> found that there is a little difference between expectation and simulation
>>>> result. For example, I set the Interest frequency as 10 (packets per
>>>> second) for 20 seconds, the result is the number of sent packets is 200
>>>> which is the same as theoretic value. But if I set the Interest frequency
>>>> as 100 for 20 seconds, the simulation result is the number of sent packets
>>>> is 1805 which is less than the theoretic value 2000. What is the possible
>>>> reason for this phenomenon? (No packets are sent from other faces)
>>>> >
>>>> > Thanks for your reply!
>>>> >
>>>> > Regards,
>>>> > huyao
>>>> > _______________________________________________
>>>> > ndnSIM mailing list
>>>> > ndnSIM at lists.cs.ucla.edu
>>>> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>>>>
>>>>
>>> _______________________________________________
>>> ndnSIM mailing list
>>> ndnSIM at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>>>
>>>
>>>
>>
>>
> _______________________________________________
> ndnSIM mailing list
> ndnSIM at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20130420/9dda20d1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 36255 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20130420/9dda20d1/attachment.png>