NFD

I've written the test case enough so that it should express an Interest on C, which will be satisfied by D. Still to do are to capture packets on the links between B and A and between A and D, as well as to parse the captured packets for CongestionMarks. In addition, we still need a way to actually get the CongestionMark added to the Interest. In a meeting, Klaus suggested creating a special strategy to do this. However, this would either require that the strategy be built into the NFD codebase or that NFD be modified in the integration tests to include this strategy.

From my meeting with Klaus today (and following up on an email exchange with Alex and Davide):

• We plan to add a strategy to NFD that will introduce the congestion mark on B. This will only be built into NFD when the "--with-tests" configuration option is specified.
• We will create a simple producer to run on D that will propagate the Interest's congestion mark on the satisfying Data.
• The test case will be modified to send an Interests under another prefix to ensure that a congestion mark is not added.
• Packets will also be captured on the C to B link (on B) to check that the initial interest does not have a congestion mark set. Packets will also be captured on the D to A link (on A), the A to B link (on B), and the B to C link (on C) to check the returning Data for a congestion mark.

I will modify the test case steps to fit our discussion in the near future.

• We plan to add a strategy to NFD that will introduce the congestion mark on B. This will only be built into NFD when the "--with-tests" configuration option is specified.

In IntegrationTests NFD is built without --with-tests, because integ should test a normal version of NFD.
Either use a separate --with-integ-helper flag, or apply necessary changes through a .diff file prior to compilation.

Junxiao Shi wrote:

• We plan to add a strategy to NFD that will introduce the congestion mark on B. This will only be built into NFD when the "--with-tests" configuration option is specified.

In IntegrationTests NFD is built without --with-tests, because integ should test a normal version of NFD.
Either use a separate --with-integ-helper flag, or apply necessary changes through a .diff file prior to compilation.

I submitted a patchset for NFD using the first of your proposed ideas.

When building other tests in NFD, the following link errors are encountered:

../tests/other/pit-fib-benchmark.cpp:44: error: undefined reference to 'nfd::tests::BaseFixture::BaseFixture()'
../tests/other/pit-fib-benchmark.cpp:44: error: undefined reference to 'nfd::tests::BaseFixture::~BaseFixture()'
../tests/other/pit-fib-benchmark.cpp:39: error: undefined reference to 'nfd::tests::BaseFixture::~BaseFixture()'
../tests/other/pit-fib-benchmark.cpp:39: error: undefined reference to 'nfd::tests::BaseFixture::~BaseFixture()'
collect2: error: ld returned 1 exit status

../tests/other/cs-benchmark.cpp:105: error: undefined reference to 'nfd::tests::makeInterest(ndn::Name const&, unsigned int)'
../tests/other/cs-benchmark.cpp:116: error: undefined reference to 'nfd::tests::makeData(ndn::Name const&)'
../tests/other/cs-benchmark.cpp:105: error: undefined reference to 'nfd::tests::makeInterest(ndn::Name const&, unsigned int)'
../tests/other/cs-benchmark.cpp:116: error: undefined reference to 'nfd::tests::makeData(ndn::Name const&)'
../tests/other/cs-benchmark.cpp:105: error: undefined reference to 'nfd::tests::makeInterest(ndn::Name const&, unsigned int)'
../tests/other/cs-benchmark.cpp:187: error: undefined reference to 'nfd::tests::makeData(ndn::Name const&)'
../tests/other/cs-benchmark.cpp:105: error: undefined reference to 'nfd::tests::makeInterest(ndn::Name const&, unsigned int)'
../tests/other/cs-benchmark.cpp:217: error: undefined reference to 'nfd::tests::makeData(ndn::Name const&)'
../tests/other/cs-benchmark.cpp:42: error: undefined reference to 'nfd::tests::BaseFixture::BaseFixture()'
../tests/other/cs-benchmark.cpp:42: error: undefined reference to 'nfd::tests::BaseFixture::~BaseFixture()'
../tests/other/cs-benchmark.cpp:38: error: undefined reference to 'nfd::tests::BaseFixture::~BaseFixture()'
../tests/other/cs-benchmark.cpp:38: error: undefined reference to 'nfd::tests::BaseFixture::~BaseFixture()'
../tests/other/cs-benchmark.cpp:42: error: undefined reference to 'nfd::tests::BaseFixture::BaseFixture()'
../tests/other/cs-benchmark.cpp:42: error: undefined reference to 'nfd::tests::BaseFixture::~BaseFixture()'
../tests/other/cs-benchmark.cpp:42: error: undefined reference to 'nfd::tests::BaseFixture::BaseFixture()'
../tests/other/cs-benchmark.cpp:42: error: undefined reference to 'nfd::tests::BaseFixture::BaseFixture()'
collect2: error: ld returned 1 exit status

That's bug #3609

I can't seem to find an existing program that will display the tags (if any) on a network packet, which is necessary for analyzing the packet traces in this test case. As such, I propose modifying the Interest/Data/Nack ostream operators in ndn-cxx to also print attached tags. This will allow this information to be gathered easily from ndn-dump.

Packets on the wire don't have tags. Packet tags are metadata attributes attached to the in-memory representation of a packet. You won't find tags in packet traces captured "on the wire". CongestionMark is an NDNLP field, therefore you need to parse the NDNLP header and look for that field. I don't know if ndndump supports inspecting NDNLP header fields.

I'm wondering why you need to look at packet traces though...

I'm assuming you'll have a custom producer app on D. This app can log the congestion mark of the incoming Interest. Likewise for the consumer on C and the received Data.

Davide Pesavento wrote:

I'm wondering why you need to look at packet traces though...

I'm assuming you'll have a custom producer app on D. This app can log the congestion mark of the incoming Interest. Likewise for the consumer on C and the received Data.

Klaus wants to verify the status of the CongestionMark at each hop.

Eric Newberry wrote:

Klaus wants to verify the status of the CongestionMark at each hop.

Why? What additional coverage does that provide?

Davide Pesavento wrote:

Eric Newberry wrote:

Klaus wants to verify the status of the CongestionMark at each hop.

Why? What additional coverage does that provide?

I believe he wants to verify that CongestionMarks get propagated on multiple hops.

Eric Newberry wrote:

I believe he wants to verify that CongestionMarks get propagated on multiple hops.

And checking the mark on C and D as I said in note-16 is not enough because...?

If needed, you can also add logging to the CongestionMarkStrategy running on B (for Interests only until #4290).

Davide Pesavento wrote:

Eric Newberry wrote:

I believe he wants to verify that CongestionMarks get propagated on multiple hops.

And checking the mark on C and D as I said in note-16 is not enough because...?

If needed, you can also add logging to the CongestionMarkStrategy running on B (for Interests only until #4290).

I agree with the changes your proposed in 16 and 20. Since the only way that CongestionMarks can currently be added is using the special CongestionMarkStrategy (which will only be run on B), they would need to be copied in order to be seen on the producer running on D. Since strategies cannot currently affect Data, the CongestionMark on the returning Data must have originated at the producer. We need Klaus' input on this, however.

Starting with the description. I'll look at the other comments in a second.

C -- B -- A -- D

These are the first 4 letters of the alphabet, but they're not in order.
Maybe rename D -> P to avoid confusion.

Route for /arizona/cs set toward B on C, toward A on B, and toward D on A. Route for /ucla/cs set toward B on C, toward A on B, and toward D on A.

Seems needlessly hard to understand.

Maybe write "P hosts both prefixes /arizona/cs and /ucla/cs. The routes are set accordingly."

Capture packets received on C from link B to C, on B from link C to B and link A to B, on A from link B to A and link D to A, and on D from link A to D.

Again, I gave up trying to parse this sentence about halfway through. Maybe I didn't sleep enough last night :)

Maybe remove all those "from link X to Y".

Steps 5. and 6. can be combined into one line.

Steps 7. to 10.:
C sends an Interest for /arizona/cs.
B adds the congestion mark (value=1) to the traversing Interest to indicate congestion.
A will propagate the congestion mark on the outgoing Interest, if it exists.
If C did not receive a Data satisfying the Interest within timeout, fail the test.

Why doesn't C also check for the congestion mark here?

Even if the marking fails, C will still receive a Data satisfying the Interest, right?

The same reasoning applies to 11. and 12.

Steps 13. to 21. look fine.

Another suggestion on the labels.

I think it's easier to understand if you label to consumer "C", the routers "Rx" (where x is a number) in order of the Interest path, and the producer "P".

So it would say:

C -- R1 -- R2 -- P

Klaus Schneider wrote:

Starting with the description. I'll look at the other comments in a second.

C -- B -- A -- D

These are the first 4 letters of the alphabet, but they're not in order.
Maybe rename D -> P to avoid confusion.

These are the names of the integration testing machines, so we're essentially stuck with them. The topology is as follows (copied from a file in the integration test repository):

B[1]---|
       +---[1]A[2]---[1]R[2]---[1]D
C[1]---|

Route for /arizona/cs set toward B on C, toward A on B, and toward D on A. Route for /ucla/cs set toward B on C, toward A on B, and toward D on A.

Seems needlessly hard to understand.

Maybe write "P hosts both prefixes /arizona/cs and /ucla/cs. The routes are set accordingly."

I feel that we need to state the exact nexthops on the route used. I have no issue combining the two routes into one sentence, however.

Capture packets received on C from link B to C, on B from link C to B and link A to B, on A from link B to A and link D to A, and on D from link A to D.

Again, I gave up trying to parse this sentence about halfway through. Maybe I didn't sleep enough last night :)

Maybe remove all those "from link X to Y".

Agreed that this is difficult to understand. I couldn't find a way to restate it with enough detail, since I feel it is necessary to state which interfaces packets will be captured on.

Even if the marking fails, C will still receive a Data satisfying the Interest, right?

Most likely, unless something else is wrong in the topology.

Also, what do you think regarding the discussion between Davide and I above?

Eric Newberry wrote:

Davide Pesavento wrote:

Eric Newberry wrote:

I believe he wants to verify that CongestionMarks get propagated on multiple hops.

And checking the mark on C and D as I said in note-16 is not enough because...?

If needed, you can also add logging to the CongestionMarkStrategy running on B (for Interests only until #4290).

I agree with the changes your proposed in 16 and 20. Since the only way that CongestionMarks can currently be added is using the special CongestionMarkStrategy (which will only be run on B), they would need to be copied in order to be seen on the producer running on D. Since strategies cannot currently affect Data, the CongestionMark on the returning Data must have originated at the producer. We need Klaus' input on this, however.

A little clarification: My idea was to check that the congestion marks can 1) be added, 2) be changed and 3) are preserved at each hop.

My initial suggestion on how to do this was to check the mark at each hop. But that's nowhere near a fixed requirement for this test.

Any way to test this is fine with me, and Davide's suggestions of using a custom consumer (#16) sounds like a good idea.

In addition, I would include a test case where the congestion mark is not only added (let's say at R1), but also changed at some point (e.g. R2). Then check at the consumer, whether it got the updated congestion mark.

Eric Newberry wrote:

Klaus Schneider wrote:

Starting with the description. I'll look at the other comments in a second.

C -- B -- A -- D

These are the first 4 letters of the alphabet, but they're not in order.
Maybe rename D -> P to avoid confusion.

These are the names of the integration testing machines, so we're essentially stuck with them. The topology is as follows (copied from a file in the integration test repository):

Maybe you can keep my (semantic) name suggestions in the description, and then use some mapping towards the actual host names?

You could even include that mapping in the code variable names?

B[1]---|
       +---[1]A[2]---[1]R[2]---[1]D
C[1]---|

Route for /arizona/cs set toward B on C, toward A on B, and toward D on A. Route for /ucla/cs set toward B on C, toward A on B, and toward D on A.

Seems needlessly hard to understand.

Maybe write "P hosts both prefixes /arizona/cs and /ucla/cs. The routes are set accordingly."

I feel that we need to state the exact nexthops on the route used. I have no issue combining the two routes into one sentence, however.

Your routing specifies exactly what would happen when someone uses ndnSIM's automatic route computation.

I think this is completely intuitive. As long as you know where the producers are, you know all the routes.

Also, what do you think regarding the discussion between Davide and I above?

See #25 above.

Klaus Schneider wrote:

Eric Newberry wrote:

Klaus Schneider wrote:

Starting with the description. I'll look at the other comments in a second.

C -- B -- A -- D

These are the first 4 letters of the alphabet, but they're not in order.
Maybe rename D -> P to avoid confusion.

These are the names of the integration testing machines, so we're essentially stuck with them. The topology is as follows (copied from a file in the integration test repository):

Maybe you can keep my (semantic) name suggestions in the description, and then use some mapping towards the actual host names?

You could even include that mapping in the code variable names?

No other integration test cases do this, so I believe it is unnecessary to do this here.

B[1]---|
       +---[1]A[2]---[1]R[2]---[1]D
C[1]---|

Route for /arizona/cs set toward B on C, toward A on B, and toward D on A. Route for /ucla/cs set toward B on C, toward A on B, and toward D on A.

Seems needlessly hard to understand.

Maybe write "P hosts both prefixes /arizona/cs and /ucla/cs. The routes are set accordingly."

I feel that we need to state the exact nexthops on the route used. I have no issue combining the two routes into one sentence, however.

Your routing specifies exactly what would happen when someone uses ndnSIM's automatic route computation.

I think this is completely intuitive. As long as you know where the producers are, you know all the routes.

The integration test cases do not use any sort of routing protocol, and all nexthops are configured manually.

Eric Newberry wrote:

Klaus Schneider wrote:

Starting with the description. I'll look at the other comments in a second.

C -- B -- A -- D

These are the first 4 letters of the alphabet, but they're not in order.
Maybe rename D -> P to avoid confusion.

These are the names of the integration testing machines, so we're essentially stuck with them. The topology is as follows (copied from a file in the integration test repository):

B[1]---|
       +---[1]A[2]---[1]R[2]---[1]D
C[1]---|

In this topology, A and D are not connected?

In addition, C -- B -- A are not as neatly in order. It is unclear to me what the hub-like element connecting B,C, and A means. That there is link between each of them?

Maybe use the nodes C -- A -- R -- D? (rather than C,B,A,D).

Klaus Schneider wrote:

Eric Newberry wrote:

Klaus Schneider wrote:

Starting with the description. I'll look at the other comments in a second.

C -- B -- A -- D

These are the first 4 letters of the alphabet, but they're not in order.
Maybe rename D -> P to avoid confusion.

These are the names of the integration testing machines, so we're essentially stuck with them. The topology is as follows (copied from a file in the integration test repository):

B[1]---|
       +---[1]A[2]---[1]R[2]---[1]D
C[1]---|

In this topology, A and D are not connected?

In addition, C -- B -- A are not as neatly in order. It is unclear to me what the hub-like element connecting B,C, and A means. That there is link between each of them?

Maybe use the nodes C -- A -- R -- D? (rather than C,B,A,D).

The topology listed in the description is the NDN topology. The one I posted in my comment above is the Ethernet topology. You can think of "+" as a switch on the Ethernet network connected to by NDN-capable hosts A, B, and C. R is only an IP router, so it doesn't run the NDN stack.

The integration test cases do not use any sort of routing protocol, and all nexthops are configured manually.

Okay, other suggestions: Use little arrows to show the routes.

"P hosts both prefixes /arizona/cs and /ucla/cs.
The routes for both prefix are as follows: C->R1, R1->R2, R2->P"

No other integration test cases do this, so I believe it is unnecessary to do this here.

I don't think "this hasn't been done before" is a very strong argument against making the description (and/or code) easier to understand.

I'm fine with just changing this description to use C, R1, R2, P. You can keep using the actual host names in the code.

Klaus Schneider wrote:

No other integration test cases do this, so I believe it is unnecessary to do this here.

I don't think "this hasn't been done before" is a very strong argument against making the description (and/or code) easier to understand.

I'm fine with just changing this description to use C, R1, R2, P. You can keep using the actual host names in the code.

The most confusing part about the current scheme is that Router B comes before A. I can remember that C is the consumer and D the producer.

But given these letters, the topology C -- A -- B -- D would be much more intuitive.

Klaus Schneider wrote:

Klaus Schneider wrote:

No other integration test cases do this, so I believe it is unnecessary to do this here.

I don't think "this hasn't been done before" is a very strong argument against making the description (and/or code) easier to understand.

I'm fine with just changing this description to use C, R1, R2, P. You can keep using the actual host names in the code.

The most confusing part about the current scheme is that Router B comes before A. I can remember that C is the consumer and D the producer.

But given these letters, the topology C -- A -- B -- D would be much more intuitive.

The topology is set up so that there is no direct IP communication between the segment containing B and C and the one containing D. Therefore, all scenarios must use A as an intermediary between these two segments, requiring the order (for all four to be used) to be C -- B -- A -- D or B -- C -- A -- D.

Furthermore, I don't believe it is necessary to have the order or names of the routers be intuitive, given that there are only four of them, as well as these tests usually won't be run by the average user.

Eric Newberry wrote:

Klaus Schneider wrote:

Klaus Schneider wrote:

No other integration test cases do this, so I believe it is unnecessary to do this here.

I don't think "this hasn't been done before" is a very strong argument against making the description (and/or code) easier to understand.

I'm fine with just changing this description to use C, R1, R2, P. You can keep using the actual host names in the code.

The most confusing part about the current scheme is that Router B comes before A. I can remember that C is the consumer and D the producer.

But given these letters, the topology C -- A -- B -- D would be much more intuitive.

The topology is set up so that there is no direct IP communication between the segment containing B and C and the one containing D. Therefore, all scenarios must use A as an intermediary between these two segments, requiring the order (for all four to be used) to be C -- B -- A -- D or B -- C -- A -- D.

Furthermore, I don't believe it is necessary to have the order or names of the routers be intuitive, given that there are only four of them, as well as these tests usually won't be run by the average user.

You have 21 lines of test cases (+ possible more once we add the tests of changing the mark), so intuitive names help us to make less mistakes.

Okay another suggestions: Can we do the tests with only 3 hosts?

C -- A -- D

D will act both as router (changing the Interest mark in one case) and as producer application. Is that possible?

Btw, if you don't think it's necessary, I won't insist on renaming the nodes.

Can you update the description with all of our previous comments (including Davide's suggestion in note-16 and my suggestion to change the data in note-25).

Maybe this will already make it easier to understand.

I can't seem to find anything about this in the NFD Developer's Guide: how do I specify parameters to a strategy with nfdc strategy set? I've tried specifying the name as /localhost/nfd/strategy/congestion-mark/1/1, but I get an error about an unknown strategy.

https://gerrit.named-data.net/4393 "tests: make CongestionMarkStrategy parameters human-readable"

This is necessary so that the parameter can be specified in the strategy name through nfdc. As the code is now, it expends a non-negative integer component, which I can find no way to encode properly through nfdc.

False. Every NDN name is representable as an URI. To pass parameter 'number 5' to the congestion mark strategy, use the following command:

nfdc strategy set /the-prefix /localhost/nfd/strategy/congestion-mark/%FD%01/%05

Junxiao Shi wrote:

False. Every NDN name is representable as an URI. To pass parameter 'number 5' to the congestion mark strategy, use the following command:

nfdc strategy set /the-prefix /localhost/nfd/strategy/congestion-mark/%FD%01/%05

Yes, but why do you want to make it more complicated than it needs to be?

why do you want to make it more complicated than it needs to be?

I do not see any complication. Names are binary, period.

I fail to see how this is related to names being binary. We're just saying that using a string representation for the number (congestion mark in this case) makes it easier for the user to specify said number as part of the strategy name on nfdc command line.

From running 4396,13 on the Vagrant environment:

host A IP addresses 192.168.1.3 and 192.168.2.2
host C IP address 192.168.1.4
host D IP address 192.168.3.3
starting nfd on host A...
starting nfd on host C...
Warning: Permanently added '192.168.1.4' (ECDSA) to the list of known hosts.
starting nfd on host D...
Warning: Permanently added '192.168.3.3' (ECDSA) to the list of known hosts.
face-created id=262 local=udp4://192.168.1.4:6363 remote=udp4://192.168.1.3:6363 persistency=persistent reliability=off
face-created id=264 local=udp4://192.168.2.2:6363 remote=udp4://192.168.3.3:6363 persistency=persistent reliability=off
route-add-accepted prefix=/arizona/cs nexthop=262 origin=static cost=0 flags=child-inherit expires=never
route-add-accepted prefix=/ucla/cs nexthop=262 origin=static cost=0 flags=child-inherit expires=never
route-add-accepted prefix=/ucsd/caida nexthop=262 origin=static cost=0 flags=child-inherit expires=never
route-add-accepted prefix=/arizona/cs nexthop=264 origin=static cost=0 flags=child-inherit expires=never
route-add-accepted prefix=/ucla/cs nexthop=264 origin=static cost=0 flags=child-inherit expires=never
route-add-accepted prefix=/ucsd/caida nexthop=264 origin=static cost=0 flags=child-inherit expires=never
strategy-set prefix=/arizona/cs strategy=/localhost/nfd/strategy/congestion-mark/%FD%01/7/true
strategy-set prefix=/ucsd/caida strategy=/localhost/nfd/strategy/congestion-mark/%FD%01/2/true
strategy-set prefix=/ucsd/caida strategy=/localhost/nfd/strategy/congestion-mark/%FD%01/3/false
.
----------------------------------------------------------------------
Ran 1 test in 12.744s

OK

Testing CongestionMark
*****************
Test script return value: 0
*****************

It would be nice if it printed a line for each successful test.

But I'm fine with the current code, let's get it merged :)