[Nfd-dev] Strategy for testbed routers

[Lan Wang (lanwang)]

Junxiao,

Just a few questions and comments:

1.  I remember the problem NDN-RTC had is the following: they have two producers connected to the same HUB, but the autoreg server gives them the same prefix even though they serve different content (each producer serves the data from a different camera).  Therefore, the forwarding strategy routes all the Interests to one of those producers (best route) or oscillates between the two producers (ncc).  They have to use broadcast strategy to get this work.  If this is the problem you are referring to, then the problem is not the forwarding strategy, but the lack of a way for the laptops to register their own prefixes with the hub (under the hub's prefix).  Is this the problem you are referring to?

2. Can you explain a bit the relationship between "NCC strategy suppresses all consumer retransmissions" and "any packet loss prevents playout of a video frame"?

3. Even on the backbone, you cannot be sure that all the available next hops in the FIB should lead you to the destination.  This really depends on the routing protocol.  If hyperbolic routing is used, it's possible that some of the next hops do not lead to the destination (due to local minima) and we have observed this.

4. Given the above, I do not feel that there is any major difference between the requirements for remote strategy and local strategy.   The following two seem to be enough:
> 	• Make use of multiple paths in FIB entry, and learn the best path.
> 	• Recovery from packet loss 


Lan
On Sep 29, 2014, at 5:46 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
 wrote:

> Dear folks
> 
> This message talks about the necessity of new/improved forwarding strategies on testbed routers, argues that characteristics for local site prefix and other prefixes are different and need two strategies, and presents the requirements for each strategy.
> This message's purpose is to agree on the requirements. This is not a design. Requirements must be defined before a design can be made.
> Please give me comments.
> 
> Necessity
> Recent experience about application performance on testbed suggests that existing strategies are insufficient to support all application scenarios.
> The most notable example is NDN-RTC: NCC strategy suppresses all consumer retransmissions so that any packet loss prevents playout of a video frame; best-route strategy cannot use multiple paths so that multiple connected laptops on the same HUB prevents video producer from being found efficiently.
> Therefore, we need new/improved forwarding strategies to use on testbed routers.
> 
> Local site prefix vs Remote prefixes
> Two types of prefixes are reachable on a given testbed router:
> A local site prefix (eg. /ndn/edu/arizona on ARIZONA router) is served by local applications on the router, and unmanaged nodes or laptops connected to the router.
> Several remote prefixes (eg. /ndn/fr/lip6 on ARIZONA router) can be reached by forwarding the Interest to other routers, where the path is learnt from routing protocols.
> 
> The characteristics of these two types of prefixes are different.
> 
> A sub-namespace under the local site prefix (eg. /ndn/edu/arizona/ndnrtc/session1) is only reachable via a small subset of nexthops installed in the FIB entry, due to the usage of nfd-autoreg-server. Even after we stop using nfd-autoreg-server, a sub-namespace under the local site prefix may become unreachable from a previously working nexthop due to mobility.
> 
> A sub-namespace under a remote prefix is usually reachable via all nexthops installed in the FIB entry, but the performance may vary between those nexthops.
> A sub-namespace under a remote prefix may become unreachable from a previously working nexthop only if there is a link failure.
> 
> Backbone router strategy and Access router strategy
> As a consequence of different characteristics of local site prefix and remote prefixes, I propose that two strategies should be designed.
> On each testbed router, the access router strategy should be assigned to the local site prefix, while the backbone router strategy should be assigned to all remote prefixes.
> On ARIZONA router, this yields a setup like: the root namespace uses backbone router strategy, /ndn/edu/arizona uses access router strategy.
> Please remember that strategy choice is inherited to sub namespaces. Setting backbone router strategy at the root namespace ensures all remote prefixes are using the backbone router strategy.
> The only exception is when a remote prefix is contained within the local site prefix, which happens on UCLA router, that needs: the root namespace and /ndn/edu/ucla/remap uses backbone router strategy, /ndn/edu/ucla uses access router strategy.
> 
> I identify the requirements of each strategy as:
> 
> Backbone router strategy should have the following features:
> 	• Make use of multiple paths in FIB entry, and learn the best path.
> 		• In the normal case, it's expected that all paths can reach the destination.
> 	• Recovery from packet loss in wide-area tunnels.
> 		• Consumer retransmission is a hint for strategy to retransmit.
> 
> Access router strategy should have the following features:
> 	• Make use of multiple paths in FIB entry, and remember which path can lead to contents.
> 		• The paths could be installed by nfd-autoreg-server, so that some paths cannot reach the producer.
> 	• Recovery from packet loss in last-hop link.
> 		• Consumer retransmission is a hint for strategy to retransmit.
> 	• Expect producer mobility.
> 
> Yours, Junxiao
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev