NFD

Potential design problem:

Should PIT entry, InRecord, OutRecord indicate that app-chosen nexthops have been used?

Forwarding strategy should not be invoked when PIT entry is satisfied, because it's not invoked during Interest processing, and would get confused.

The complication is that a PIT entry may aggregate both downstreams with app-chosen nexthops, and downstreams without this option.

Good question... Having reference to strategy in PIT (or out record) seem to solve the problem, but it also looks like additional overhead...

May be we should update the processing and instead of bypassing the strategy, just use the list of supplied FaceId as a suggested input to the strategy (instead of FIB-based nexthops). Would that be better?

When app-chosen nexthops is used, the Interest MUST go to all these nexthops immediately.

Strategy has different behavior: send all, try one by one, or ignore nexthop list completely.

Strategy should not be relied on (and should not be required) to deal with app-chosen nexthops.

We talked yesterday and there is actually a very simple solution to the problem. Bypassing the strategy is actually not a common operation that should work for all possible prefixes, but a special operation that should work at least for the routing daemon.

So. What we have decided is that we require a special strategy to be set for the prefix, and this special strategy would require explicit FaceId in LocalControlHeader in order to do any kind of forwarding. In other words, we not going to have any special treatment for LocalControlHeader, rather we make a separate strategy that known exclusively about the LocalControlHeader. Given this, the Interest processing pipeline gets a little simpler, and the problem you mentioned will not exist anymore.

There is an option to use Faces specified in LocalControlHeader as a suggestion for the strategy. But this still is not necessary and having a special dedicated strategy for dealing with LocalControlHeader-specified faces is enough.

This approach would work for both routing application and traceroute. In traceroute case, the trace server is actually registering a special /trace/ prefix and does (directed) forwarding only within this prefix (e.g., to trace /ndn/edu/ucla, ndn-traceroute will try to send interests to /trace/ndn/edu/ucla, which will be handled entirely by the traceroute daemon).