[Nfd-dev] ncc strategy

[Lan Wang (lanwang)]

Can you give a detailed explanation of the observed behavior and how/why the patch improved the results?

Also why didn't Arizona switch back to the faster path when CSU came back?

Lan
On Sep 10, 2014, at 11:09 AM, Syed Obaid Amin <obaidasyed at gmail.com<mailto:obaidasyed at gmail.com>>
 wrote:

Hi Junxiao,

Thanks for the fix. The patch improved the results significantly. For e.g., have a look at the following results:

Old strategy:
http://netwisdom.cs.memphis.edu/hr_evaluation/tests-withfailure-oldncc_nolog/arizona-caida-converge.png

Patched:
http://netwisdom.cs.memphis.edu/hr_evaluation/tests-withfailure-ncc_nolog/arizona-caida-converge.png

The topology I used for these tests can be found here:
http://netwisdom.cs.memphis.edu/imgs/topology.png

Regards,
Obaid



On Mon, Sep 8, 2014 at 7:36 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:
Hi Lan

Bug 1961 has been fixed. Code is merged to master branch.
Please test in your internal testbed.

The correct behavior shall be:

  1.  P1 is forwarded to UCLA, and could be forwarded to CSU and other nexthops as well
  2.  UCLA responds first and remains as best face; other responses are received but ignored
  3.  P2 should be forwarded to UCLA

This bug is not critical to end users. I don't plan to backport to v0.2. It won't be deployed on testbed routers until v0.3 release.

Yours, Junxiao


On Tue, Sep 2, 2014 at 10:26 AM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:
Hi Lan

Thanks for the report. This shall be a bug of NCC strategy.

In ccnd,

  1.  When first Data comes back that satisfies the PIT entry, the incoming face of that Data is remembered.
  2.  The PIT entry is deleted as soon as it's satisfied.
  3.  When second Data comes back, it's discarded as unsolicited.

In NFD,

  1.  When first Data comes back that satisfies the PIT entry, the incoming face of that Data is remembered.
  2.  The PIT entry is kept, and will be deleted after straggler timer.
  3.  When second Data comes back, the strategy is notified, and remembers the incoming face.

NFD's NCC strategy incorrectly assumes the incoming Data is from the fastest upstream, causing the bug.

I'll report the bug soon.

Yours, Junxiao


On Tue, Sep 2, 2014 at 10:03 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Junxiao,

We observed something strange in one of our experiments when we used the ncc strategy (and link state routing).  In some of the pings from Arizona to PKU, the ndnping delays were really large (>350ms) even though the shortest path delay is only around 200ms.  We looked at the ndnping data, and found where the delay jumped from ~200ms to ~350ms.  It turns out that instead of going through the shortest path (Arizona->UCLA->PKU), it is going through a much longer path (Arizona->CSU->…->NEU->PKU).

To explain what happened, I'll call the ping before the change P1 and the ping after the change P2.  Further looking into the nfd logs, it seems for P1 Arizona first sent the Interest to UCLA (which we expected), but while waiting for the data to come back, it also tried CSU and some other neighbors.  The ping Data did come back from the shortest path (PKU->UCLA->Arizona) as expected.  But afterwards, the ping Data also comes back from the other much longer paths.  The problem is that Arizona seems to remember the most recent successful paths instead of the previously successful shorter paths.  Next time when P2 came, it directly sent the Interest to CSU instead of UCLA.

Is this expected behavior of ncc?  I want to emphasize that the shorter path did return the same Ping data (and much earlier than the longer path).

Lan


_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140910/b44f8019/attachment.html>