[Nfd-dev] ncc strategy

Junxiao Shi shijunxiao at email.arizona.edu
Wed Sep 10 11:24:13 PDT 2014


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).
   - 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.


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


More information about the Nfd-dev mailing list