[Nfd-dev] ncc strategy

Junxiao Shi shijunxiao at email.arizona.edu
Wed Sep 10 13:29:28 PDT 2014


Hi Obaid

The experiment results from ccnd shows that ccnd is also unable to detect
the recovery of the best path. It would stick with the second path until it
fails, or until traffic stops so measurements are gone.
Therefore, it's a weakness of ccnd strategy, and not a bug of NCC strategy.

I'll certain consider this scenario when designing a new strategy for
routers (Task 1901).

Yours, Junxiao

On Wed, Sep 10, 2014 at 12:19 PM, Syed Obaid Amin <obaidasyed at gmail.com>
wrote:

>
>
> On Wed, Sep 10, 2014 at 1:24 PM, Junxiao Shi <shijunxiao at email.arizona.edu
> > wrote:
>
>> Hi Lan
>>
>> The fix for Bug 1961 improve the results because it ensures an upstream
>> who isn't first to respond won't be incorrectly recorded as best face.
>>
>> The patched figure shows two links are used. ARIZONA-CSU-CAIDA has RTT
>> 72ms; ARIZONA-MEMPHIS-CAIDA has RTT 156ms.
>> CSU node fails at message 60, and recovers at message 180.
>> The experiment ends at message 300.
>>
>> *NCC strategy fails to switch back to CSU after its recovery. This is
>> either a weakness of ccnd strategy, or a misunderstand when it's ported to
>> NFD.* This is not an experiment problem, and cannot be solved by running
>> experiment for longer time.
>> Detail analysis follows.
>>
>> NCC strategy maintains an RTT prediction for the best face of each Name
>> prefix. The granularity is at Interest Name minus the last component
>> (usually a segment number).
>>
>>    - RTT prediction starts at 8.192ms.
>>    - If Data comes within prediction, prediction is adjusted down by
>>    1/128, and minimum is 0.127ms.
>>    - If Data doesn't come within prediction, prediction is adjusted up
>>    by 1/8, and maximum is 160ms.
>>    - The effect of above two point is: ultimately, prediction oscillates
>>    around real RTT (if real RTT is between 0.127ms and 160ms).
>>    - If Data doesn't come within prediction, other faces will be tried,
>>    starting from the end of original prediction.
>>    The previous best face, along with one other face who has lowest
>>    routing cost, are tried first.
>>    Other faces are tried one by one, in a short period of time.
>>
>> Two important points are:
>>
>>    - All except the best face are propagated to, after the prediction.
>>    This means, the Interest is forwarded to CSU 154ms (=156*127/128) later
>>    than forwarding to MEMPHIS.
>>    - Incoming face of the first Data that satisfies the Interest becomes
>>    the best face. If the MEMPHIS link does not fail, the Data would always
>>    arrive first, because the Interest is forwarded 154ms earlier. Therefore, *CSU
>>    link can never become the best face, unless MEMPHIS link fails, or until
>>    the traffic stops so that measurements are wiped out*. This is
>>    confirmed by my calculation in Excel.
>>
>> Questions:
>>
>>    - Does the routing protocol uninstall and re-install the Route during
>>    this experiment? If yes, please give the time point at which the FIB update
>>    is applied (a time point shall be given as "just before sending Interest
>>    for message X" so that I can correlate to messages).
>>
>> Not sure what do you mean here. At 60th sec, the CSU node was brought
> down, as a result all other nodes update their routing tables. But we don't
> have any timestamps as the logging was not on.
>
>
>>
>>    - If you have results of a similar experiment with ccnd or ndnd,
>>    please share them, so that I can confirm whether it's a design weakness or
>>    implementation bug.
>>
>> I've data from ccnx, but that experiment ran for 180 secs only. I am
> attaching here the file. If seems useful I can re-run the experiments with
> ccnx. But it may take little time for exact setup.
>
>  Regards,
> Obaid
>
>
>>
>>    -
>>
>>
>> Yours, Junxiao
>>
>> On Wed, Sep 10, 2014 at 9: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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140910/f3c5e304/attachment.html>


More information about the Nfd-dev mailing list