Write specification for NLSR NACK behavior.
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.
#3 Updated by Nicholas Gordon over 2 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?
#5 Updated by Lan Wang over 2 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.