Project

General

Profile

Actions

Task #4391

closed

Feature #1624: Design and Implement Congestion Control

Congestion Control: Test Local Link Loss Detection

Added by Anonymous almost 7 years ago. Updated almost 7 years ago.

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

100%

Estimated time:

Description

As follow up to Feature #3823, we need to test whether the Local Link Loss Detection (and notification) works as expected.

This task should be to design and discuss unit tests to verify the correct behavior of #3823.


Related issues 1 (0 open1 closed)

Related to NFD - Feature #3823: Congestion Control: design Local Link Loss DetectionClosedEric Newberry

Actions
Actions #1

Updated by Anonymous almost 7 years ago

  • Related to Feature #3823: Congestion Control: design Local Link Loss Detection added
Actions #2

Updated by Anonymous almost 7 years ago

Here's the relevant earlier discussion:

Eric Newberry wrote:

I ran a test, but it appears that onLostPacket is being called for every frame, even if it has been successfully acknowledged on its first transmission.

Klaus Schneider wrote:

What might cause this bug?

Eric Newberry wrote:

No idea. The timeout calling onLpLostPacket should be cancelled when its frame goes out of scope (when the UnackedFrag object containing it is deleted). Given that the initial RTO is 1 second and ndnping is reporting an RTT in the 10s of milliseconds on the link, I am at a loss.

Davide Pesavento wrote:

Klaus Schneider wrote:

Looks like we need a more formal integration test for this?

Not necessarily an integration test. A unit test should be able to catch this kind of bugs.

Actions #3

Updated by Eric Newberry almost 7 years ago

  • Tracker changed from Task to Bug
  • Status changed from New to In Progress
  • Priority changed from Normal to High
  • Target version set to v0.7
Actions #4

Updated by Eric Newberry almost 7 years ago

  • Status changed from In Progress to Feedback

It looks like this may not actually be an issue. I forgot that reliability must be manually enabled on both ends of the link for the system to function. It looks like the packets were being received, but not acknowledged, leading to onLpPacketLost being called due to the expiration of the timeout.

I ran the test again, using tc to drop approximately 10% of packets on the receiver and it appears that the strategy was notified whenever onLpPacketLost was called (with retx=0, so this is expected upon every call to onLpPacketLost).

Actions #5

Updated by Anonymous almost 7 years ago

Can you give a specific, step-by-step instruction of your testing? (i.e. list the terminal commands and files that need editing).

Actions #6

Updated by Davide Pesavento almost 7 years ago

  • Tracker changed from Bug to Task
  • Priority changed from High to Normal

So there's no bug here, correct?

Actions #7

Updated by Eric Newberry almost 7 years ago

Davide Pesavento wrote:

So there's no bug here, correct?

Not to my knowledge. Here's how I performed my testing (if my memory serves right):

  1. Set up a VirtualBox VM with a host-only network adapter, allowing it to be reached over the network from the host machine. Install an unmodified version of NFD on the VM.
  2. On the host machine, modify, compile, and install NFD to include a message to cout in BestRouteStrategy2::onDroppedInterest (creating this function in the process), as well as in LpReliability::onLpPacketLost to print before onDroppedInterest is signaled.
  3. Start NFD both on the host machine and the VM.
  4. Create a UDP face on the host machine, with the VM as the remote endpoint, enabling reliability: nfdc face create udp4://[remote-ip-addr] reliability on
  5. Run the corresponding nfdc command on the VM to enable reliability from that end of the connection.
  6. Use tc on the VM to simulate 10% packet loss on the host-only interface: sudo tc qdisc add dev enp3s0 root netem loss 10%
  7. Start ndnpingserver on the VM to serve a particular prefix.
  8. Start ndnping on the host machine for the prefix mentioned above.
  9. Examine the output of NFD on the host machine to ensure that both messages are being printed to cout.
Actions #8

Updated by Davide Pesavento almost 7 years ago

Great. I suggest rejecting this task unless someone can describe an integration test scenario that tests something not already covered by unit tests.

Actions #9

Updated by Davide Pesavento almost 7 years ago

  • Description updated (diff)

Oh wait, this task is about unit tests, not integration tests. LpReliability already has numerous unit tests though, is there something that is not covered by them? Please explain in the description exactly what tests are needed, if any, otherwise reject.

Actions #10

Updated by Eric Newberry almost 7 years ago

Davide Pesavento wrote:

Oh wait, this task is about unit tests, not integration tests. LpReliability already has numerous unit tests though, is there something that is not covered by them? Please explain in the description exactly what tests are needed, if any, otherwise reject.

We could add a unit test to ensure that the loss timeout is cancelled when an Ack in received for the packet. I already have this test case written, so I'll go ahead and push it for code review.

Actions #11

Updated by Anonymous almost 7 years ago

Eric Newberry wrote:

Davide Pesavento wrote:

Oh wait, this task is about unit tests, not integration tests. LpReliability already has numerous unit tests though, is there something that is not covered by them? Please explain in the description exactly what tests are needed, if any, otherwise reject.

We could add a unit test to ensure that the loss timeout is cancelled when an Ack in received for the packet. I already have this test case written, so I'll go ahead and push it for code review.

Sounds good.

Actions #12

Updated by Davide Pesavento almost 7 years ago

  • Status changed from Feedback to In Progress

You can get a rough idea of what is not covered here: http://jenkins.named-data.net/job/NFD/5879/OS=code-coverage/LCOV_Coverage_Report/daemon/face/lp-reliability.cpp.gcov.frameset.html
For example, receiving Acks for unknown TxSequence is not tested, the nRetransmitted counter is not tested, and so on.

Actions #13

Updated by Eric Newberry almost 7 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 0 to 100
Actions #14

Updated by Eric Newberry almost 7 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF