[Nfd-dev] ncc strategy

[Lan Wang (lanwang)]

Junxiao,

Thank you very much.  Obaid will try the new code and verify the behavior.

Lan
On 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


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