Project

General

Profile

Actions
Copy link

Task #2000

open

Composable strategy building blocks

Added by Junxiao Shi about 10 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Forwarding
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
40.00 h

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

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

Updated by Junxiao Shi about 10 years ago

  • Blocks Feature #1756: Let strategy pick outgoing Interest packet added
Actions
Copy link
 #2

Updated by Junxiao Shi over 9 years ago

  • Description updated (diff)
Actions
Copy link
 #3

Updated by Junxiao Shi over 9 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

Actions
Copy link
 #4

Updated by Junxiao Shi almost 8 years ago

  • Blocks deleted (Feature #1756: Let strategy pick outgoing Interest packet)
Actions
Copy link
 #5

Updated by Junxiao Shi over 7 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.

Actions
Copy link
 #6

Updated by Junxiao Shi over 7 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.

Actions
Copy link
 #7

Updated by Nicholas Gordon over 7 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 (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.

Actions
Copy link
 #8

Updated by Junxiao Shi over 7 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.

Actions
Copy link
 #9

Updated by Ju Pan about 5 years 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)

Thanks.

Actions
Copy link
 #10

Updated by Junxiao Shi over 4 years 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.

Actions
Copy link

Also available in: Atom PDF