[Nfd-dev] ncc strategy

[Junxiao Shi]

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>
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>
> 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/20140908/53bd0997/attachment.html>