[ndnSIM] Best Route acting weird

Mon Feb 20 10:44:27 PST 2017

Junxiao,

Thank you so much. You're right!! I guess this shows what you said:

3s 0 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%03?ndn.InterestLifetime=2000&ndn.Nonce=1638928127 from=259
> newPitEntry-to=257
> 4s 0 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%03?ndn.InterestLifetime=2000&ndn.Nonce=1585152108 from=259
> retransmit-unused-to=256
> 4.01028s 1 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%03?ndn.InterestLifetime=2000&ndn.Nonce=1585152108 from=256
> newPitEntry-to=257
> 4.02056s 2 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%03?ndn.InterestLifetime=2000&ndn.Nonce=1585152108 from=257
> newPitEntry-to=259
> 5s 0 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%04?ndn.InterestLifetime=2000&ndn.Nonce=3464367241 from=259
> newPitEntry-to=257
> 6s 0 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%04?ndn.InterestLifetime=2000&ndn.Nonce=433302024 from=259
> retransmit-unused-to=256
> 6.01028s 1 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%04?ndn.InterestLifetime=2000&ndn.Nonce=433302024 from=256
> newPitEntry-to=257
> 6.02056s 2 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%04?ndn.InterestLifetime=2000&ndn.Nonce=433302024 from=257
> newPitEntry-to=259
>
> 10s 0 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%07?ndn.InterestLifetime=2000&ndn.Nonce=3530243069 from=259
> newPitEntry-to=257
> 11s 0 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%06?ndn.InterestLifetime=2000&ndn.Nonce=2402032498 from=259
> newPitEntry-to=257
> 12s 0 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%08?ndn.InterestLifetime=2000&ndn.Nonce=1055204503 from=259
> newPitEntry-to=257
> 13s 0 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%09?ndn.InterestLifetime=2000&ndn.Nonce=3593408063 from=259
> newPitEntry-to=257
> 14s 0 nfd.BestRouteStrategy2:afterReceiveInterest(): [DEBUG]
> /prefix/%FE%07?ndn.InterestLifetime=2000&ndn.Nonce=85550101 from=259
> newPitEntry-to=257
>

So, the helper does not really fail a link. Isn't failing/uping a link what
it actually supposed to do?

What is RetxSuppressionExponential? Actually I can see what it does. But,
why is it separated from the strategy itself?

About you suggestion. Do we have any kind of implementation of BFD(rfc
5880/7880) for NDN in any level?

Thanks,
Sabet

On Mon, Feb 20, 2017 at 8:25 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Sabet
>
> This may be related to the retransmission behavior of
> ns3::ndn::ConsumerCbr.
>
> I can see that ndn::LinkControlHelper::FailLink does not cause
> face->getStatus() to become DOWN, and there is no BFD running, so the face
> will remain UP from strategy point of view.
> Your scenario uses static routes, so that 0->2 route would remain active
> even if the link is having 100% loss rate.
> As long as face->getState() is UP and the route is still active, NFD
> best-route v4 keeps using 0->2 route when an Interest is received for the
> first time, and will try 0->1 route only if the consumer retransmit the
> Interest (same Name+Selectors+Link, different Nonce).
> Moreover, a consumer retransmission can cause best-route v4 to use 0->2
> route only if it arrives no later than InterestLifetime expiration (2
> seconds in your scenario), and no earlier than best-route's suppression
> timer (10ms for the first retransmission).
>
> ns3::ndn::ConsumerCbr expresses a new Interest every 1 second with
> InterestLifetime 2000ms, and retransmits an unsatisfied Interest after RTO.
> RTO is computed using TCP's algorithm, bounded between 0.2 and 200 seconds.
> When Data arrives, its RTT is added to the RttEstimator if the Interest
> has not been retransmitted. On the other hand, if an Interest times out (no
> Data within RTO), the RTO multiplier doubles, up to 64. The multiplier can
> be reset to 1 only if a Data arrives without any Interest retransmission.
> Combine this with the behavior of best-route v4, we can see that, since
> best-route v4 requires consumer retransmission for every Interest in order
> to retrieve Data via 0->1 route, the multiplier would never get reset.
> Eventually, the RTO would exceed InterestLifetime, and therefore the
> retransmitted Interest would not be detected by best-route v4 as consumer
> retransmission.
>
> Your log shows, Interest for seq 6 is initially sent at 9.0s. RTO timeout
> occurs at 10.6s. Then, the logic in ConsumerCbr schedules the
> retransmission at 11.0s.
> This is exactly the case I described above: at 11.0s, PIT entry is gone
> because InterestLifetime has expired, so that best-route v4 would detect
> the Interest as a new Interest instead of a retransmission, and forward it
> toward 0->2 route which is having 100% loss rate.
> This is the expected behavior of best-route v4, and it's not a NFD bug.
>
>
> To make this scenario work better, suggestions are:
>
>    - Implement BFD in the face, making face->getState() report as DOWN,
>    so that strategy would not use the face.
>    - Use AccessStrategy, which can switch to 0->1 route if 0->2 isn't
>    working. But it won't switch back.
>    - Change either InterestLifetime or max RTO, so that max RTO (plus
>    ConsumerCbr's scheduling delay) is less than InterestLifetime.
>
>
> Yours, Junxiao
>
>
> On Sat, Feb 18, 2017 at 11:26 AM, Muhammad Hosain Abdollahi Sabet <
> mhasabet at gmail.com> wrote:
>
>> Hi there,
>>
>> I was trying to show the impact forwarding plane and forwarding strategy
>> in failure detection with a simple scenario in ndnSIM:
>>
>>   ndn::FibHelper::AddRoute(nodes.Get(0),ndn::Name("/prefix"),
>>> nodes.Get(2),1);
>>>   ndn::FibHelper::AddRoute(nodes.Get(1),ndn::Name("/prefix"),
>>> nodes.Get(2),20);
>>>   ndn::FibHelper::AddRoute(nodes.Get(0),ndn::Name("/prefix"),
>>> nodes.Get(1),20);
>>>
>>>   ndn::StrategyChoiceHelper::Install(nodes.Get(0),
>>> ndn::Name("/prefix"), "/localhost/nfd/strategy/best-route");
>>>
>>>   // Consumer
>>>   ndn::AppHelper consumerHelper("ns3::ndn::ConsumerCbr");
>>>   consumerHelper.SetPrefix("/prefix");
>>>   consumerHelper.SetAttribute("Frequency", StringValue("1"));
>>>   consumerHelper.Install(nodes.Get(0));
>>>
>>>   // Producer
>>>   ndn::AppHelper producerHelper("ns3::ndn::Producer");
>>>   producerHelper.SetPrefix("/prefix");
>>>   producerHelper.SetAttribute("PayloadSize", StringValue("1024"));
>>>   producerHelper.Install(nodes.Get(2));
>>>
>>>   Simulator::Schedule(Seconds(3.0), ndn::LinkControlHelper::FailLink,
>>> nodes.Get(0), nodes.Get(2));
>>>   Simulator::Schedule(Seconds(15.0), ndn::LinkControlHelper::UpLink,
>>> nodes.Get(0), nodes.Get(2));
>>>
>>
>> It works fine at first and detects the failure so tries with the other
>> face from 4s to 8s. But After 9s, Consumer tries sending interest while nfd
>> does not send it:
>>
>> 9s 0 ndn.Consumer:SendPacket()
>>> 9s 0 ndn.Consumer:SendPacket(): [INFO ] > Interest for 6
>>> 9s 0 ndn.Consumer:WillSendOutInterest(): [DEBUG] Trying to add 6 with
>>> +9000000000.0ns. already 0 items
>>> 10s 0 ndn.Consumer:SendPacket()
>>> 10s 0 ndn.Consumer:SendPacket(): [INFO ] > Interest for 7
>>> 10s 0 ndn.Consumer:WillSendOutInterest(): [DEBUG] Trying to add 7 with
>>> +10000000000.0ns. already 1 items
>>> 10.6s -1 ndn.Consumer:OnTimeout(6)
>>> 11s 0 ndn.Consumer:SendPacket()
>>> 11s 0 ndn.Consumer:SendPacket(): [INFO ] > Interest for 6
>>> 11s 0 ndn.Consumer:WillSendOutInterest(): [DEBUG] Trying to add 6 with
>>> +11000000000.0ns. already 1 items
>>>
>>
>>  As soon as UpLink event, consumer tries with the first face and
>> retrieves data. Why is that? Is it a kind of bug in nfd?
>>
>> Thanks,
>> Sabet
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20170220/f8fb46bb/attachment-0001.html>