Project

General

Profile

Actions

Task #3799

closed

Write specification for NLSR NACK behavior.

Added by Nicholas Gordon over 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Immediate
Target version:
Start date:
10/06/2016
Due date:
% Done:

0%

Estimated time:

Description

Currently no part of NLSR handles NACKs that are generated by the network. Since these contain very valuable information about the state of the network and ndn-cxx has deprecated the expressInterest method that does not process them, we need to update NLSR to process NACKs. To do this, we need to define the ideal reactions to NACKs by NLSR across all situations and NACK reasons. Then it will be possible to implement NLSR NACK reactions.


Files

nack-spec.pdf (86.8 KB) nack-spec.pdf Specification draft, v2 Nicholas Gordon, 10/06/2016 10:26 AM
nack-spec.pdf (97 KB) nack-spec.pdf NACK specification, v3. Nicholas Gordon, 10/07/2016 01:12 PM
nack-spec.pdf (96.4 KB) nack-spec.pdf NACK specification draft, v4. Nicholas Gordon, 10/07/2016 02:43 PM
nack-spec.pdf (89 KB) nack-spec.pdf NACK specification draft, v5. Nicholas Gordon, 10/14/2016 12:48 PM
nack-spec.pdf (92.6 KB) nack-spec.pdf NACK specification draft, v6. Nicholas Gordon, 10/17/2016 11:15 AM
nack-spec.pdf (93.8 KB) nack-spec.pdf NACK Specification draft, v7 Nicholas Gordon, 12/05/2016 09:38 AM

Related issues 1 (0 open1 closed)

Related to NLSR - Task #3815: Handle NACKs in Sync module.Rejected10/17/2016

Actions
Actions #1

Updated by Nicholas Gordon over 7 years ago

I have added a section describing NLSR's behavior in response to NACKs of FaceStatus dataset.

Actions #2

Updated by Nicholas Gordon over 7 years ago

Added a new draft.

Actions #3

Updated by Nicholas Gordon over 7 years ago

There are a few questions that I have:

  1. If NLSR sends a Hello interest to another router where NLSR is not running, will that router return "no route" as its NACK reason?
  2. If NLSR sends a Hello Interest to a non-existent router, will the NFD instance give a "no route" NACK?
  3. If a Face is down, what will NFD do when an interest is sent to it? Will NFD attempt to send it?
Actions #4

Updated by Nicholas Gordon over 7 years ago

Added a new draft, with many revisions.

Actions #5

Updated by Lan Wang over 7 years ago

Here're some comments on the latest draft:

  1. add a default case for each type of interest. The behavior should be just logging the NACK and do nothing else.

  2. since congestion NACK is not implemented yet, remove it from the LSA interest part. However, do add a Redmine issue to handle congestion NACK when it is implemented and link that issue to this one.

  3. wherever a resend is required, please specify the details (e.g., default and range of waiting time before resending the interest). Note if exponential increase of waiting time is required, there is more details to specify. "wait a short while" is too vague. In general, give as much information as possible to whoever is going to implement this protocol so anyone should be able to arrive at the same implementation after reading the specification.

  4. I don't think we should keep resending any LSA interest (or other interests except for those that are periodic in nature) in any case. This can generate a storm if some node is disconnected and other nodes keep asking it for its LSAs (at least for a while). We should always have a limit on the number of retries.

  5. NACKs of sync interests: ideally this should not happen very often if the multicast strategy handles NACKs well. However, this is just my guess. For now, we should log these NACKs to see if these happen often. I suppose we will need to modify the SYNC module to do so. In addition, we should add a Redmine issue to handle the Sync interest NACKs and link that issue with this one. If there's indeed many NACKs seen by the SYNC module, we should work on the new Redmine issue (before we integrate the new sync).

  6. add a figure to illustrate the Duplicate Nack case on page 2. It's difficult to understand without a figure.

Actions #6

Updated by Nicholas Gordon over 7 years ago

  • Related to Task #3815: Handle NACKs in Sync module. added
Actions #7

Updated by Nicholas Gordon over 7 years ago

Revised some sections and added specific numbers to some sections. Added a figure to and elaborated on the duplicate NACK scenario.

Actions #8

Updated by Nicholas Gordon over 7 years ago

Revised some of the language at the bottom. Since this has had no activity for over a month, if no one has any feedback I will assume that there are no objections.

Actions #9

Updated by Nicholas Gordon almost 7 years ago

  • Status changed from In Progress to Closed
Actions

Also available in: Atom PDF