Feature #3157
closed
Added by Junxiao Shi about 9 years ago.
Updated almost 8 years ago.
Category:
Integration Tests
Description
Develop an IntegrationTests scenario to test Nack with best-route strategy.
Topology:
B
|
A---D
|
C
Procedure:
- start NFD on A,B,C,D
- configure NFD on A,C,D to use best-route strategy
- configure NFD on B to use best-route v1 strategy, which will not transmit or process Nack
- 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
- on D, create a route for prefix
ndn:/P toward A
- 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
- 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
- configure NFD on B to use best-route strategy
- on B and C, configure unidirectional link delay toward A as 500ms
- 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
- on B, configure unidirectional link delay toward A as 1000ms
- 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
- Blocked by Feature #3156: NACK in forwarding and best-route added
- Blocked by Feature #3104: NDNLPv2: GenericLinkService encoding/decoding added
- Subject changed from NACK scenario to Nack scenario
- Description updated (diff)
- Assignee set to Hila Ben Abraham
- Status changed from New to In Progress
I need a couple of clarifications:
- 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?
- 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)?
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.
- % 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.
- 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.
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.
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?
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.
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?
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.
- Target version changed from v0.4 to v0.5
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?
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.
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.
- Status changed from Feedback to Closed
- Target version changed from v0.5 to v0.6
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by