Task #2000

Composable strategy building blocks

Added by Junxiao Shi almost 6 years ago. Updated 2 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
40.00 h


Design a framework for composing strategy from building blocks.

A building block is a functional unit in forward strategy.

A forwarding strategy can be composed by connecting building blocks in a certain way, so that it has certain features and behaviors.

The design should answer the following:

  • What building blocks are needed?
  • How building blocks can be connected together?
  • How do building blocks store information (such as measurements)?
  • Can stored information be shared?
  • Demonstrate how to compose commonly used strategies.
  • How to protect against a malicious strategy?
  • How to improve efficiency of a composed strategy?


Scanned_20170427-0910.pdf (390 KB) Scanned_20170427-0910.pdf Junxiao Shi, 04/27/2017 09:11 AM

Updated by Junxiao Shi over 5 years ago

  • Blocks Feature #1756: Let strategy pick outgoing Interest packet added

Updated by Junxiao Shi about 5 years ago

  • Description updated (diff)

Updated by Junxiao Shi almost 5 years ago

I received one scenario which can potentially be solved by composing a strategy:

it's a specific case that I don't want a local face, which has the matching FIB entry for an interest, to receive that interest from one local application, while it can receive that interest from another remote application


Updated by Junxiao Shi over 3 years ago

  • Blocks deleted (Feature #1756: Let strategy pick outgoing Interest packet)

Updated by Junxiao Shi about 3 years ago

Records from 20150707 meeting:

Necessity of composable/combinable strategy: most strategies will need retransmission, scoping (ScopeControl), and congestion control features. Thus, they should become building blocks.


Updated by Junxiao Shi about 3 years ago

I also made examples of multicast strategy and best-route strategy composed from building blocks.
Caution: They are from 20150707 so they may not match the later design.


Updated by Nicholas Gordon about 3 years ago

This may only be tangentially related, and it may already be well-known by Junxiao and others, but I've recently read the Click router paper (, and I think it is very closely related to this idea. This can at least serve as collected knowledge on this issue.


Updated by Junxiao Shi about 3 years ago

Click modular router is exactly where this idea comes from. NFD's forwarding pipelines design is also inspired by Click.
However, implementing the whole NDN router in Click is difficult, because NDN makes heavy use of states. Each table can be translated into an element in Click, but the complexity of such element violates Click's principle of composing simple elements together.


Updated by Ju Pan 9 months ago

Dear folks, I was asked to look into this task. There is not too much information in this thread over 5 years. Due to my limited experience with NFD, could someone help answer the following questions?

  1. Is it possible to implement this for the current NFD?
  2. If possible, what are the hard parts? (or why nobody touches this task in 5 years)



Updated by Junxiao Shi 2 months ago

  • Assignee deleted (Junxiao Shi)

This is a design task, not an implementation task.

Is it possible to implement this for the current NFD?

Yes, everything is possible.

If possible, what are the hard parts? (or why nobody touches this task in 5 years)

It needs to completely rewrite forwarding pipelines into a modular structure.
The difficulty in getting agreement with reviewers make me scared.

Also available in: Atom PDF