NFD

20150903 conference call approves the design in note-3.

This issue will remain open until NACK behavior of all strategies are designed.

best-route design in note-3 has a limitation:

  P
  |
  R
 / \
B---C
|   |
A   D

In this topology, P announces /P prefix, every link has a delay of 10ms, retransmission suppression is configured at 2ms.

1. 0ms: A and D express Interest /P/1 at the same time. A's Interest is forwarded along A-B-R; B's Interest is forwarded along D-C-R.
2. 5ms: A and D retransmits the Interest at the same time. A's Interest is forwarded along A-B-C; B's Interest is forwarded along D-C-B.
3. 20ms: R receives the two Interests from step1, but notices R-P link has failed, and thus returns a Nack to B and C.
4. 25ms: B and C receive the two Interests from step2, and forward them again to R.
5. 30ms: B and C receive the Nack from R. B is still waiting for the response from C, so it will not return the Nack to A and C at this moment. C is still waiting for the response from B, so it will not return the Nack to D and B at this moment.
6. 35ms: R receives the two Interests from step4, and returns Nack again because R-P link is still down.
7. 45ms: B and C receive the Nack again from R. But B is still waiting for C, and C is still waiting for B.

Both B and C are waiting for each other, until InterestLifetime expires. No Nack can be sent in this situation.

I think the time of 2. should be "15ms" so that the other times match up.

Isn't the retransmission timeout of the scenario (5ms? 15ms?) shorter than expected from real applications?

Does the problem still exist when the retx timeout is higher than the RTT to the producer? (my guess would be that it would not)

Reply to note-8:

The timestamp is note-7 step2 is intended to be 5ms. The Interest expressed by A in this step arrives at B at +15ms, and arrives at C at +25ms in step4, where C forwards it to R.

Consumers can set any retransmission timer as they want. The "exponential suppression" procedure (#1913) permits the first retx after 1ms, so a retransmission after 5ms will be forwarded.

Even if we could blame the consumer in this scenario, a slightly different case would be: there are two consumers A1 and A2 connected to B; A1 expresses an Interest in step1, and A2 expresses an Interest in step2. This leads to the same situation.

20150910 conference call discussed note-7 "live deadlock" problem.

The solution is:
At step5, B should return NACK to C, because at this moment B is unable to satisfy C's Interest without using C as an upstream.
But B shouldn't return NACK to A yet, because C could return Data to satisfy A.
C does the same and returns NACK to B.
After B receives the NACK from C, B would be able to return NACK to A because both R and C have returned NACK.

I'll update the design to fix this problem.

Note-7 only describes a 2-node scenario, which can be easily extend to an "n-node live deadlock" case. Therefore, a more general condition to handle nack is that - if all upstreams that are not downstream have returned NACK, a NACK is sent back to all downstream.

"n-node live deadlock" case.

Draw a topology and write a packet timing sequence to explain what this is.