Project

General

Profile

Actions

Feature #3662

closed

NotificationSubscriber: Nack

Added by Junxiao Shi over 7 years ago. Updated over 7 years ago.

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

0%

Estimated time:
2.00 h

Description

Handle Nack in NotificationSubscriber.


Related issues 2 (1 open1 closed)

Related to ndn-cxx - Feature #3663: NotificationSubscriber: ValidatorNew

Actions
Blocks ndn-cxx - Task #3334: Deprecate Face::expressInterest non-Nack overloadsClosedZhiyi Zhang

Actions
Actions #1

Updated by Junxiao Shi over 7 years ago

  • Blocks Task #3334: Deprecate Face::expressInterest non-Nack overloads added
Actions #2

Updated by Junxiao Shi over 7 years ago

  • Related to Feature #3663: NotificationSubscriber: Validator added
Actions #3

Updated by Junxiao Shi over 7 years ago

  • Assignee set to Teng Liang

Teng agrees to work on this issue within a week.

Actions #4

Updated by Teng Liang over 7 years ago

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.

Actions #5

Updated by Teng Liang over 7 years ago

  • Status changed from New to In Progress
Actions #6

Updated by Teng Liang over 7 years ago

  • Status changed from In Progress to Code review
Actions #7

Updated by Junxiao Shi over 7 years ago

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.

Actions #8

Updated by Junxiao Shi over 7 years ago

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.

Actions #9

Updated by Teng Liang over 7 years ago

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]

Actions #10

Updated by Junxiao Shi over 7 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF