Task #2000
open
Composable strategy building blocks
Added by Junxiao Shi over 9 years ago.
Updated almost 4 years ago.
Description
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?
Files
- Blocks Feature #1756: Let strategy pick outgoing Interest packet added
- Description updated (diff)
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
- Blocks deleted (Feature #1756: Let strategy pick outgoing Interest packet)
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.
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.
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 (https://github.com/kohler/click), and I think it is very closely related to this idea. This can at least serve as collected knowledge on this issue.
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.
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?
- Is it possible to implement this for the current NFD?
- If possible, what are the hard parts? (or why nobody touches this task in 5 years)
Thanks.
- 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
Updated by 
Updated by 
Updated by