[ndnSIM] Best Route acting weird

[Junxiao Shi]

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/20170219/e3c39b5b/attachment.html>