Project

General

Profile

Feature #3157

Nack scenario

Added by Junxiao Shi almost 5 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
Integration Tests
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
6.00 h

Description

Develop an IntegrationTests scenario to test Nack with best-route strategy.

Topology:

B
|
A---D
|
C

Procedure:

  1. start NFD on A,B,C,D
  2. configure NFD on A,C,D to use best-route strategy
  3. configure NFD on B to use best-route v1 strategy, which will not transmit or process Nack
  4. on A, create a route for prefix ndn:/P toward B and C, where the cost toward B is lower than the cost toward C
  5. on D, create a route for prefix ndn:/P toward A
  6. on D, express an Interest for ndn:/P/1 with InterestLifetime=4000ms and no consumer retransmission;
    wait 8000ms since expressing Interest, fail the scenario if Nack comes back;
    reason: A shouldn't generate a Nack when upstream times out
  7. on D, express an Interest for ndn:/P/2 with InterestLifetime=4000ms, and retransmit with a new Nonce after 200ms;
    wait 8000ms since expressing first Interest, fail the scenario if Nack comes back;
    reason: A shouldn't return a Nack when some upstream times out, even if some other upstream returns Nack
  8. configure NFD on B to use best-route strategy
  9. on B and C, configure unidirectional link delay toward A as 500ms
  10. on D, express an Interest for ndn:/P/3 with InterestLifetime=4000ms, and retransmit with nonce2 after 200ms;
    wait 3000ms since expressing first Interest, expect exactly one Nack comes back where Reason is NoRoute and Nonce equals nonce2, otherwise fail the scenario;
    reason: A should return a Nack after both upstreams have returned Nack
  11. on B, configure unidirectional link delay toward A as 1000ms
  12. on D, express an Interest for ndn:/P/4 with InterestLifetime=4000ms, and retransmit with nonce2 after 200ms;
    wait 3000ms since expressing first Interest, expect exactly one Nack comes back where Reason is NoRoute and Nonce equals nonce2, otherwise fail the scenario;
    reason: the Nack should carry the latest incoming Nonce from downstream, not the Nonce from last incoming Nack

Files

20161026145052.tgz (575 KB) 20161026145052.tgz integ 3283,4 Junxiao Shi, 10/26/2016 09:27 AM
20161109193307.tgz (594 KB) 20161109193307.tgz Hila Ben Abraham, 11/09/2016 12:56 PM
20161115205445.tgz (575 KB) 20161115205445.tgz Verified patch set 11 Hila Ben Abraham, 11/16/2016 12:00 PM
20161118002228.tgz (575 KB) 20161118002228.tgz integ 3283,12 Junxiao Shi, 11/17/2016 05:38 PM

Related issues

Blocked by NFD - Feature #3156: NACK in forwarding and best-routeClosedJunxiao Shi

Actions
Blocked by NFD - Feature #3104: NDNLPv2: GenericLinkService encoding/decodingClosedEric Newberry

Actions
#1

Updated by Junxiao Shi almost 5 years ago

  • Blocked by Feature #3156: NACK in forwarding and best-route added
#2

Updated by Junxiao Shi almost 5 years ago

  • Blocked by Feature #3104: NDNLPv2: GenericLinkService encoding/decoding added
#3

Updated by Junxiao Shi almost 5 years ago

  • Subject changed from NACK scenario to Nack scenario
  • Description updated (diff)
#4

Updated by Hila Ben Abraham over 4 years ago

  • Assignee set to Hila Ben Abraham
#5

Updated by Hila Ben Abraham over 4 years ago

  • Status changed from New to In Progress
#6

Updated by Hila Ben Abraham over 4 years ago

I need a couple of clarifications:

  1. Step 2 requires best-route while step 3 requires best-route v1. Does nfd support both? I thought that best-route2 is what we refer as the current best-route strategy, so what is best-route v1?
  2. Whenever the procedure requires setting the link delay - can I assume a specific interface is used (such as eth0/1) or should I add it as a configurable parameter (such as in multi-host.conf)?
#7

Updated by Junxiao Shi over 4 years ago

Answer to note-6:

NFD supports both best-route and best-route v1. To select best-route v1: nfdc set-strategy /namespace /localhost/nfd/strategy/best-route/%FD%01.

You can neither hard-code a specific interface nor add it as a configuration parameter.
Instead, parse the output of ip addr with awk or sed or grep, and find which interface has $IP4_B1.
The script should be able to handle the situation when $IP4_B1 is a proper prefix of an IP on another interface; for example: "eth1 10.0.0.1; eth2=10.0.0.11; $IP4_B1=10.0.0.1", the script should not find eth2.

#8

Updated by Hila Ben Abraham about 4 years ago

  • % Done changed from 0 to 80

An update: I will submit the task once I have it tested on ONL. It will probably take a few more days since ONL has been recently moved and not yet up again.

#9

Updated by Hila Ben Abraham almost 4 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 80 to 100

I finally got to test this task and I found that I can't get the generated nonce of an outgoing Interest when using PyNDN2. Therefore, I cannot verify steps 10 and 12 in which the returned NACK should carry nonce2.

I used PyNDN2 to implement the script that sends and retransmits Interests as required in steps: 6,7,10,12.

I would like to suggest adding getGeneratedNonce(interestId) API to the pendingInterestTable module. If needed, I can submit the test code for review without the nonces validation.

#10

Updated by Junxiao Shi almost 4 years ago

I used PyNDN2 to implement the script that sends and retransmits Interests as required in steps: 6,7,10,12.

Do not add dependency on PyNDN. PyNDN code is not reviewed by NFD developers.

Instead, use ndn-cxx for the consumer program.

#11

Updated by Hila Ben Abraham almost 4 years ago

OK. What would be the appropriate way to build the consumer? Can I add it as the initial test step? Or should I support it as part of the 'install_helpers' step?

#12

Updated by Junxiao Shi almost 4 years ago

OK. What would be the appropriate way to build the consumer? Can I add it as the initial test step? Or should I support it as part of the 'install_helpers' step?

Talk to Eric. He's doing something similar in #1942.

#13

Updated by Hila Ben Abraham almost 4 years ago

After discussing it with Eric we suggest one of the following options:

1. Adding new apps to a new 'tools' directory, possibly under install_helpers, 
   and supporting a single build system that builds all apps during the initialization phase.

2. Having each test support its own consumer/producer apps as part of the test run.

I personally think the first choice is preferred, but open to hear other suggestions.
Any thoughts?

#14

Updated by Junxiao Shi almost 4 years ago

I prefer the first option in note-13.
For simplicity:

  • use a Makefile
  • keep each program to a single cpp file when feasible
  • in each program source code, insert a comment to indicate which test case(s) uses this program

The above rules should appear in tools/README.

Note that infoedit should not be treated in the same way; #3387 is still valid.

#15

Updated by Davide Pesavento almost 4 years ago

  • Target version changed from v0.4 to v0.5
#17

Updated by Hila Ben Abraham over 3 years ago

Two tests fail according to the results attached in note-16.

* test_remote_register
* test_nack

First, is test_remote_register expected to fail?

Second, test_nack fails on stage #10 since there is no nack coming back (both Interests timeout). Since it is working on my environment, I wonder whether there is a restriction on configuring delays on Emulab. I don't see any error for those commands so I assume it is something else.
Is it possible to run NFD in higher severity log to check the problem?

#18

Updated by Junxiao Shi over 3 years ago

is test_remote_register expected to fail?

#3825

Is it possible to run NFD in higher severity log to check the problem?

You may invoke infoedit to edit NFD configuration file and increase log levels. You may even invoke tcpdump to save traffic trace.

#19

Updated by Hila Ben Abraham over 3 years ago

I was finally able to fix the problem and verified the test using ndn-cxx-breaks. I will clean up the code and upload a version for review.

#22

Updated by Junxiao Shi over 3 years ago

  • Status changed from Feedback to Closed
  • Target version changed from v0.5 to v0.6

Also available in: Atom PDF