Project

General

Profile

Actions

Bug #3786

closed

Interest with Link not forwarded after same Interest without Link is Nacked or timed out

Added by Haitao Zhang over 7 years ago. Updated about 2 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
Forwarding
Target version:
-
Start date:
09/16/2016
Due date:
% Done:

0%

Estimated time:

Description

Case 1

Topology and route:

       /a

   A ------> B
  1. A expresses Interest i1 /example/testApp/randomData without Link object.
  2. A waits for i1 to timeout.
  3. A delays a short period of time (see below).
  4. A expresses Interest i2 /example/testApp/randomData with Link object delegating /example/testApp to /a.

Expected: Interest i2 is forwarded to B.

Actual: Interest i2 is not forwarded to B if step3 delay is less than 100ms. The behavior is as expected if step3 delay is greater than 100ms.

Case 2

Topology and route:

       /example      /a

   C <---------- A ------> B
  1. A expresses Interest i1 /example/testApp/randomData without Link object; InterestLifetime is set to 1000ms.
  2. i1 is forwarded to C.
  3. C responds Nack-NoRoute to A.
  4. A waits for the Nack.
  5. A delays a short period of time (see below).
  6. A expresses Interest i2 /example/testApp/randomData with Link object delegating /example/testApp to /a.

Expected: Interest i2 is forwarded to B.

Actual: Interest i2 is forwarded to C if step5 delay is less than 1000ms. The behavior is as expected if step5 delay is greater than 1000ms.


Related issues 1 (1 open0 closed)

Is duplicate of NFD - Feature #3162: PIT: index with forwarding hintNew

Actions
Actions #1

Updated by Junxiao Shi over 7 years ago

  • Is duplicate of Feature #3162: PIT: index with forwarding hint added
Actions #2

Updated by Junxiao Shi over 7 years ago

  • Subject changed from The logic of processing interest with link after processing the same interest without link is not correct to Interest with Link not forwarded after same Interest without Link is Nacked or timed out
  • Description updated (diff)
  • Category set to Forwarding

The cause of both cases is the same: the PIT entry for i1 is still alive when i2 arrives at forwarder A, and i2 is mistakenly aggregated into the same PIT entry rather than creating a new PIT entry.

The incorrect PIT aggregation is due to not-yet-implemented #3162 which would give i1 and i2 separate PIT entry.

#3162 itself cannot start until #3333 is either resolved or rejected.

Actions #3

Updated by Junxiao Shi about 2 years ago

  • Status changed from New to Duplicate
Actions

Also available in: Atom PDF