Task #3032
closed
Determine rules to combine NackReasons
Added by Junxiao Shi over 9 years ago.
Updated over 9 years ago.
Description
Suppose:
- An Interest is sent to more than one upstreams.
- All upstreams have returned NACKs.
- Incoming NACKs have more than one unique reasons.
- The strategy has decided that there's no alternate path, and a NACK should be returned to downstream(s).
What NackReason should be contained in the NACK returned to downstream(s)?
It's strategy's responsibility to determine the NackReason to be returned.
This issue is to find an answer to this question, so that it serves as a recommendation to strategy designs.
This issue requires no coding, but should produce a document that summarize the recommendation.
- Estimated time changed from 3.00 h to 1.50 h
20150706 conference call discussed this question.
Lixia's opinion is:
- At this moment, only two reasons are defined: Duplicate and GiveUp.
- If upstreams have returned a mix of Duplicate and GiveUp, GiveUp should be returned to downstream(s) because GiveUp is severer than Duplicate.
- In the future, when a new reason is defined, a relative ordering should be established among all reasons, and the severest reason should be returned.
I have no objection for defining a relative ordering, but I don't understand why GiveUp is severer than Duplicate.
In the future, when a new reason that can carry Suggestion fields is defined, we also need to consider what suggestions can be passed along.
But this discussion can be deferred to the future.
20150710 conference call discussed this problem.
@Beichuan points out that the current definition of GiveUp, "the upstream has attempted to forward the Interest, but no Data can be retrieved after exhausting all available routes", is flawed.
This is actually a definition of NACK (probably except "has attempted to forward" part), and it shouldn't be a NackReason.
Beichuan suggests the following NackReason to be defined:
- Congestion
- Duplicate
- NoRoute (including routing problem and link failure, because differentiating these two does not help downstream)
The least severe NackReason should be passed to downstream.
A less severe reason gives the downstream more opportunity to try this upstream again.
The severity order among reasons are: Congestion < Duplicate < NoRoute.
- Status changed from New to Closed
note-2 rules is added into #3033 note-3 design.
- Related to Task #3033: Forwarding design: Nack added
I need to decide on the NackReason codes.
In #2520 note-21, I'm using these codes:
- Congestion=50
- Duplicate=100
- NoRoute=150
The "least severe" algorithm is a simple integer comparison.
The code assignment also leaves enough gap between two codes, so that new NackReasons can be assigned in the gap to maintain the severity order.
The alternate is to assign consecutive codes without considering severity order.
The "least severe" algorithm would need to go through a fixed-size table.
It's more complex but still a constant time algorithm.
20150803 conference call approves the code assignments in note-5.
Also available in: Atom
PDF
Updated by