NFD » ndn-cxx

There is no description of handling NACK in the notification wiki. As a NACK can be generated by multiple reasons, it is proper to treat it as the same as a timeout; a subscriber will restart with the initial request after receiving a NACK.

Reply to note-4:

It might be harmful to immediately restart the subscriber with an initial Interest, especially when the Nack was returned against an initial Interests.

Consider the case a subscriber is fetching a notification stream that is unroutable.
The router would immediately return a Nack-NoRoute.
If the subscriber immediately resends the Interest, the router would return the Nack again, and so on, leading to high bandwidth usage.

Similarly, in case of a Nack-Congestion, immediately resending the Interest can only worsen the congestion.

For both Nack-NoRoute and Nack-Congestion, a reasonable reaction is to wait for a random delay before resending the initial Interest.
The delay duration can be randomized between 5% and 20% of InterestLifetime.

I cannot think about the best reactions for other Nack reasons and reasonless Nacks, but the same reaction should work as well.

20160719 call decides that it's necessary to have a delay after Nack before resending the initial Interest.
The delay should use an exponential back-off policy, plus a small randomization to avoid synchronization.

Junxiao Shi wrote:

20160719 call decides that it's necessary to have a delay after Nack before resending the initial Interest.
The delay should use an exponential back-off policy, plus a small randomization to avoid synchronization.

Here is the rough description of the implementation design:

The method exponentialBackoff() is added to calculate the delay time after receiving a Nack. The variable lastNackSeq is used to check if the same Interest is Nacked again;
if true, attempts += 1; otherwise, attempts = 1; the delayTime is then calculated and returned.
delayTime = pow(2, attempts) * 100 ms + a random value in [1ms, 100ms]