[Nfd-dev] Strategy for testbed routers

[Junxiao Shi]

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>
wrote:

>
>  On Sep 30, 2014, at 6:43 PM, Junxiao Shi <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/20141001/574d7ec3/attachment.html>