[Nfd-dev] ncc strategy

Wed Sep 10 11:24:37 PDT 2014

I cannot say if the patch fixed the Bug 1961 completely, as I don't have
detailed nfd logs with me and without them I cannot trace packets. But it
does improve the results, in terms of RTT. I am going to run the experiment
with DEBUG log level now and will update you about it.

@Junxiao,  I've a few questions regarding NCC can you please explain?

1. The result of old ncc kind of contradicts what you explained earlier. If
an RTT of duplicate data is not getting discarded in old ncc, then why
packet coming via Memphis didn't update the face priorities. What it means
that after bringing down CSU node, the RTT shouldn't stay to 350ms for more
than 2 mins?

2. Did the patch fixed other issues too? As now with the new patch the
strategy doesn't use the best path once it is back again?

3. How face priorities are updated, does the strategy update the the
priorities as soon as the Data packet arrives or it waits for sometime, if
so for how long it waits?

4. Is there any refresh period for reprioritizing the faces?

Thanks,
Obaid

On Wed, Sep 10, 2014 at 11:17 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

>  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>
>  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>
> 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/5cc84d58/attachment.html>