Task #3799
closed
Write specification for NLSR NACK behavior.
Added by Nicholas Gordon about 8 years ago.
Updated over 7 years ago.
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
|
|
I have added a section describing NLSR's behavior in response to NACKs of FaceStatus dataset.
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?
Added a new draft, with many revisions.
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.
- Related to Task #3815: Handle NACKs in Sync module. added
Revised some sections and added specific numbers to some sections. Added a figure to and elaborated on the duplicate NACK scenario.
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.
- Status changed from In Progress to Closed
Also available in: Atom
PDF
Updated by 
Updated by