[Nfd-dev] ncc strategy

[Syed Obaid Amin]

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>
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
> > 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
>>
>>
>
> _______________________________________________
> Nfd-dev mailing list
> 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/92d6acc4/attachment.html>