Project

General

Profile

Actions

Task #3032

closed

Determine rules to combine NackReasons

Added by Junxiao Shi over 9 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Forwarding
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
1.50 h

Description

Suppose:

  1. An Interest is sent to more than one upstreams.
  2. All upstreams have returned NACKs.
  3. Incoming NACKs have more than one unique reasons.
  4. 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.


Related issues 1 (0 open1 closed)

Related to NFD - Task #3033: Forwarding design: NackClosedJunxiao Shi

Actions
Actions #1

Updated by Junxiao Shi over 9 years ago

  • 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.

Actions #2

Updated by Junxiao Shi over 9 years ago

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.

Actions #3

Updated by Junxiao Shi over 9 years ago

  • Status changed from New to Closed

note-2 rules is added into #3033 note-3 design.

Actions #4

Updated by Junxiao Shi over 9 years ago

  • Related to Task #3033: Forwarding design: Nack added
Actions #5

Updated by Junxiao Shi over 9 years ago

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.

Actions #6

Updated by Junxiao Shi over 9 years ago

20150803 conference call approves the code assignments in note-5.

Actions

Also available in: Atom PDF