Project

General

Profile

Bug #2055

No strategy can support realtime traffic over lossy link when autoreg is used

Added by Junxiao Shi about 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Forwarding
Target version:
Start date:
10/13/2014
Due date:
% Done:

0%

Estimated time:

Description

Scenario

  • A gateway router is running nfd-autoreg which registers the same prefix for all connected laptops, using the same Route Cost.
  • Multiple laptops are connected to the router.
  • Each laptop serves a distinct prefix, which is a child prefix of the prefix registered by nfd-autoreg.
  • The connection between laptop and router is lossy. Interest retransmission is needed to recover from packet loss.
  • Traffic is realtime: delay is tolerable up to 500ms.

Expected: There exists a strategy that can allow contents retrieval in this scenario.

Actual: None of the existing strategies (best-route, ncc, broadcast) can support this scenario.

ncc and broadcast strategies are able to reach the correct laptop that can serve the Interest.
However, when there is a packet loss, these strategies don't permit Interest retransmission before InterestLifetime is over, so that packet loss is unrecoverable.

best-route strategy allows Interest retransmission once every 100ms, and retranmitted Interest goes to different nexthops in a round-robin fashion, where the nexthops are used in a fixed order.
It can recover from packet loss, and can reach the correct laptop after several retransmissions.

However, the realtime traffic can only tolerate 500ms delay, which allows at most 5 retranmissions.
Since Interest retransmission is triggered by consumer, consumer must have precise timing that lines up with the retransmission timer of best-route strategy in order to have 5 retransmissions, which is nearly impossible.

Even with 5 retransmission, when there are three laptops connected, the Interest will go in the order (laptopA, laptopB, laptopC, laptopA, laptopB).
If the correct laptop happens to be laptopC, a packet loss is unrecoverable.


Related issues

Related to ndnrtc - Bug #2054: NdnCon cannot fetch if connected to a HUB with multiple clientsClosed10/13/2014

Actions
Blocked by NFD - Feature #1999: Strategy for access routerClosedJunxiao Shi

Actions
#1

Updated by Junxiao Shi about 7 years ago

  • Has duplicate Bug #2054: NdnCon cannot fetch if connected to a HUB with multiple clients added
#2

Updated by Junxiao Shi about 7 years ago

#3

Updated by Junxiao Shi about 7 years ago

  • Has duplicate deleted (Bug #2054: NdnCon cannot fetch if connected to a HUB with multiple clients)
#4

Updated by Junxiao Shi about 7 years ago

  • Related to Bug #2054: NdnCon cannot fetch if connected to a HUB with multiple clients added
#5

Updated by Klaus Schneider almost 7 years ago

Hi everyone,

I think this is a worthwhile scenario, but I am wondering if the strategy layer is the right place to implement this functionality.

Let's say there are 100 laptops which serve a child prefix (e.g., /ndn/shared/laptopXX). Then for each child prefix the FIB of the gateway router would have 1 correct and 99 incorrect entries. Clearly, round-robin won't be very useful in this case.

Wouldn't it be more efficient to create a mechanism that registers the exact prefix of each laptop? Then even the simplest forwarding strategy would suffice since there is only one FIB entry.

Moreover, isn't it possible to reduce the InterestLifetime (e.g., to 100ms) and then let the application do the re-transmission? Then the strategy could send re-transmitted Interests on the previously recorded best/correct path.

You mentioned (http://redmine.named-data.net/attachments/download/169/access-router-strategy_20141022.pptx) some problems with matching the InterestLifetime to RTT. Can you elaborate on that?

Thanks a lot.

#6

Updated by Junxiao Shi almost 7 years ago

We already have a mechanism that registers the exact prefix of each laptop: remote prefix registration (#2056).

However, even with that, the FIB may not be 100% accurate, thus some support in the strategy is necessary.

#7

Updated by Junxiao Shi almost 7 years ago

  • Status changed from New to Resolved
  • Assignee set to Junxiao Shi

The access router strategy is designed to solve this issue.

Testbed routers should choose access router strategy for all namespaces except broadcast.

Although access router strategy isn't designed for prefixes leading to remote sites, it's expected to perform no worse than NCC or best route.

End hosts should still choose best route strategy.

#8

Updated by Junxiao Shi over 6 years ago

  • Status changed from Resolved to Closed

I'm closing this Bug since no feedback is entered in past 4 weeks.

Also available in: Atom PDF