[Nfd-dev] Strategy for testbed routers

[Lan Wang (lanwang)]

Junxiao,

It seems that the main difference is whether the previously failed path is probed frequently or not.  I think it's ok to define the different strategies based on the assumption of whether the failed path is expected to come back shortly or not.  On the other hand, it is also possible to use one strategy and let it learn how frequently it should probe the failed paths based on past history.  In any case, I don't have an objection to split the strategies into two for now.

Lan
On Oct 1, 2014, at 9:50 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Lan

2.
The problem is not "primary path is not working", but "primary path is working most of the time, but happens to lose one packet". Retrying on the same path helps.

3.
Forwarding strategy need not make an assumption on what routing protocol is used, but it should know the quality of paths.
High quality routes (such as those from link state routing) can reach the destination UNLESS there's a fault. Retrying is less aggressive, and a temporarily failed path is expected to come back shortly so probing is frequent.
Low quality routes (such as those from autoreg-server) are more likely to be incorrect. Retrying is aggressive, and a path that does not work is assumed to be an incorrect path so probing is infrequent.

4.
Backbone router strategy assumes all paths can reach the destination UNLESS there's a fault. If there's a fault, Interests go to backup path, but probing is frequent so that traffic can switch back to primary path once it comes back.
Access router strategy. When a working path is found, probing on other paths is infrequent. When producer is believed to be moved, the strategy won't expect the old path to work again until the new path fails (which means producer is moving again).

Yours, Junxiao

On Wed, Oct 1, 2014 at 7:56 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

On Sep 30, 2014, at 6:43 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Lan

1.
Yes, the root cause is that laptops are unable to register a precise prefix on the access router.
The most effective solution is to enable remote prefix registration on the access router.

2.
NCC strategy forwards an Interest to a nexthop, and that nexthop is never used again before InterestLifetime expires.
When there is a packet loss, even if the consumer is able to detect that and retransmit the Interest, the retransmission is suppressed by NCC strategy because it won't forward the Interest again to the same nexthop.
When a Data does not reach consumer before it's needed, the video frame cannot be constructed and cannot play out.

If the Interest was forwarded along some alternative paths by NCC, then it should still reach the producer and bring back the data, right?  And if the primary path is not working, sending the Interest there again probably won't help much either.  I just want to have a clear understanding of this problem for NDN-RTC on the testbed and then it's more clear how a more effective strategy should work.

3.
Link state routing can ensure all nexthops in FIB entry can reach the destination.
Backbone strategy is designed for this scenario.

Strategy choice depends on network environment and application needs.
Hyperbolic routing might need a different strategy.

I'm not sure if the forwarding strategy should make an assumption of what routing protocol is used.  After all, the routing protocol may be relying on the forwarding strategy to fix some of the temporary problems so that it doesn't have to respond as quickly as in an IP network (Cheng's paper).

4.
The distinction between remote prefixes and local site prefix is: remote prefixes have mostly reachable nexthops and less changes (when link state routing is used), local site prefix suffers more from unreachable nexthops and laptop mobility.
I don't know whether there is a major difference in the structure of those two forwarding strategies, but they will at least differ in some parameter settings.

It seems to me that as long as the forwarding strategy satisfies the requirement of "Make use of multiple paths in FIB entry, and learn the best path.", then it can handle various failure situations (whether they are caused by laptop mobility or link failures).  It would be better if you can make it clear what extra is required for local site prefix.

Lan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20141008/670228f3/attachment.html>