[Nfd-dev] Strategy for testbed routers

[Junxiao Shi]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140929/04a842a8/attachment.html>