Task #3799
closedWrite specification for NLSR NACK behavior.
0%
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
Updated by Nicholas Gordon about 8 years ago
- File nack-spec.pdf nack-spec.pdf added
I have added a section describing NLSR's behavior in response to NACKs of FaceStatus dataset.
Updated by Nicholas Gordon about 8 years ago
- File nack-spec.pdf nack-spec.pdf added
Added a new draft.
Updated by Nicholas Gordon about 8 years ago
There are a few questions that I have:
- If NLSR sends a Hello interest to another router where NLSR is not running, will that router return "no route" as its NACK reason?
- If NLSR sends a Hello Interest to a non-existent router, will the NFD instance give a "no route" NACK?
- If a Face is down, what will NFD do when an interest is sent to it? Will NFD attempt to send it?
Updated by Nicholas Gordon about 8 years ago
- File nack-spec.pdf nack-spec.pdf added
Added a new draft, with many revisions.
Updated by Lan Wang about 8 years ago
Here're some comments on the latest draft:
add a default case for each type of interest. The behavior should be just logging the NACK and do nothing else.
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.
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.
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.
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).
add a figure to illustrate the Duplicate Nack case on page 2. It's difficult to understand without a figure.
Updated by Nicholas Gordon about 8 years ago
- Related to Task #3815: Handle NACKs in Sync module. added
Updated by Nicholas Gordon about 8 years ago
- File nack-spec.pdf nack-spec.pdf added
Revised some sections and added specific numbers to some sections. Added a figure to and elaborated on the duplicate NACK scenario.
Updated by Nicholas Gordon almost 8 years ago
- File nack-spec.pdf nack-spec.pdf added
- Priority changed from High to Immediate
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.
Updated by Nicholas Gordon over 7 years ago
- Status changed from In Progress to Closed