Project

General

Profile

Task #2053

Strategy choice in config file

Added by Alex Afanasyev almost 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Management
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
9.00 h

Description

Initial configuration of strategies is extremely important operation. I have seen so many reports on the mailing list of improper strategy settings, which will be non-existent if only we had initial default settings in the config file.

This task is to add an option in the configuration file to configure strategies for namespaces. This will duplicate strategy management protocol, but both of them serve different purposes---one initial config and the other runtime configuration.

History

#1 Updated by Anonymous almost 5 years ago

  • Assignee set to Anonymous

nfd.conf currently defines a "tables" section with the following comment: "The tables section configures the CS, PIT, FIB, Strategy Choice, and Measurements tables". Should this task be implemented as a "strategy" subsection that represents Strategy Choice and lists (prefix, strategy name) pairs?

Example:

tables
{
  cs_max_packets 65536

  strategy
  {
    / /localhost/nfd/strategy/ncc
    /foo /localhost/nfd/strategy/bestroute
  }
 }

#2 Updated by Alex Afanasyev almost 5 years ago

Yeah. I like this. Would this be ok for the INFO format parser?

#3 Updated by Junxiao Shi almost 5 years ago

  • Subject changed from Add (duplicate) strategy configuration in config file to Strategy choice in config file

tables section contains characteristics of tables, such as size limit and replacement policy.

Strategy choice is the contents of a table, which needs its own section:

strategy_choices {
  / /localhost/nfd/strategy/best-route
  /ndn /localhost/nfd/strategy/ncc
  /ndn/broadcast /localhost/nfd/strategy/broadcast
}

When management module processes the configuration, conceptually it should start retrieving the strategy code (remember that strategies could be written in a scripting language and need to be retrieved), and set strategy choice once strategy code is retrieved.

daemon/fw/available-strategies.cpp should still set a default strategy, which will take effect before strategy retrieval is complete.

#4 Updated by Anonymous almost 5 years ago

I think it's confusing to have one section (tables) to configure one aspect of a table and another (counter-proposed strategy_choice in note-3) to configure others. Ideally, there should be a single place for configuring all aspects of a table and I think having strategy_choice as a subsection of tables is the best way in the current config format.

However, this task describes something that was not intended when we first added the tables section. Does it make more sense to get rid of tables entirely and give each table its own config section?

#5 Updated by Junxiao Shi almost 5 years ago

I agree with note-4 that strategy_choices can be a subsection of tables.

Don't get rid of tables and create one section per table.

We have face_system section for all faces, so we can have tables for all tables.

#6 Updated by Junxiao Shi almost 5 years ago

  • Start date deleted (10/12/2014)
  • Estimated time set to 9.00 h

Remember to update NFD Developer Guide with the changes, as part of this Task.

#7 Updated by Anonymous almost 5 years ago

  • Status changed from New to Code review
  • % Done changed from 0 to 100

#8 Updated by Anonymous almost 5 years ago

  • % Done changed from 100 to 80

Still need to update developer guide.

#9 Updated by Anonymous almost 5 years ago

  • % Done changed from 80 to 100

Updated the developer guide (just a small addition). I did not update the guide's revision history.

I'll close this task if there's no response/request for changes in 24 hours or so.

#10 Updated by Anonymous almost 5 years ago

  • Status changed from Code review to Closed

Also available in: Atom PDF