Bug #2055
closedNo strategy can support realtime traffic over lossy link when autoreg is used
0%
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.
Updated by Junxiao Shi about 10 years ago
- Has duplicate Bug #2054: NdnCon cannot fetch if connected to a HUB with multiple clients added
Updated by Junxiao Shi about 10 years ago
- Blocked by Feature #1999: Strategy for access router added
Updated by Junxiao Shi about 10 years ago
- Has duplicate deleted (Bug #2054: NdnCon cannot fetch if connected to a HUB with multiple clients)
Updated by Junxiao Shi about 10 years ago
- Related to Bug #2054: NdnCon cannot fetch if connected to a HUB with multiple clients added
Updated by Anonymous almost 10 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.
Updated by Junxiao Shi almost 10 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.
Updated by Junxiao Shi almost 10 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.
Updated by Junxiao Shi over 9 years ago
- Status changed from Resolved to Closed
I'm closing this Bug since no feedback is entered in past 4 weeks.