Project

General

Profile

Actions

Feature #3034

closed

ContentStore miss pipeline: process Link for mobility

Added by Junxiao Shi over 8 years ago. Updated over 8 years ago.

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

100%

Estimated time:
4.50 h

Description

In ContentStore miss pipeline, process Link for mobility support.

This issue contains the minimal changes to support mobility with Link.

Cache poisoning and measurement inaccuracy problems will be solved later.

NFD Developer Guide should be updated to document this feature.


Related issues 5 (1 open4 closed)

Related to NFD - Feature #3000: Design mobility with forwarding hintFeedback

Actions
Blocks NFD - Feature #3074: Mobility with Link scenarioClosedEric Newberry

Actions
Blocked by NFD - Feature #3155: Ensure packet is well-formed before entering pipelinesClosedJunxiao Shi

Actions
Blocks NFD - Feature #3159: NetworkRegionTable configuration optionClosedVince Lehman

Actions
Blocks NFD - Feature #3664: Incoming Nack pipeline: consider Link during FIB lookupClosedJunxiao Shi

Actions
Actions #1

Updated by Junxiao Shi over 8 years ago

  • Related to Feature #3000: Design mobility with forwarding hint added
Actions #2

Updated by Junxiao Shi over 8 years ago

  • Blocked by Feature #3026: RouterName configuration option added
Actions #3

Updated by Junxiao Shi over 8 years ago

  • Status changed from New to In Progress
Actions #4

Updated by Junxiao Shi over 8 years ago

  • % Done changed from 0 to 50
Actions #5

Updated by Junxiao Shi over 8 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 50 to 100
Actions #6

Updated by Junxiao Shi over 8 years ago

Actions #7

Updated by Junxiao Shi over 8 years ago

  • Blocked by deleted (Feature #3026: RouterName configuration option)
Actions #8

Updated by Junxiao Shi over 8 years ago

  • Status changed from Code review to In Progress
  • % Done changed from 100 to 50

Due to design change in #3000 note-20, I need to rework "in producer region" algorithm.

I plan to add the "region names" configuration option in the same commit. To avoid global state (as pointed out in #3049), the design is:

  1. Forwarder exposes a setRegionNames(const std::set<Name>&) method, and a getter for unit testing.
  2. Rename nfd::general::setConfigFile to nfd::general::processConfigFile (to better reflect that it is stateless), and add a Forwarder& parameter to this function; this function calls forwarder.setRegionNames(..).
Actions #9

Updated by Alex Afanasyev over 8 years ago

I agree with note-8 change.

Actions #10

Updated by Junxiao Shi over 8 years ago

I'm looking at current Forwarder API and I think I shouldn't introduce a setRegionNames setter method and put matching logic inside Forwarder, because region names are part of the forwarder's state, and state should go into a table.

I plan to add a table as follows:

class RegionSet : public std::set<Name>
{
public:
  /** \brief determines whether an Interest has reached a producer region
   */
  bool
  isInProducerRegion(const Interest& interest) const;
};

This allows optimizations on the table without affecting Forwarder.

This also allows future management protocol to manipulate the table, or create dataset out of the table, without requiring direct access to Forwarder.

nfd::general::processConfigFile will receive a reference to this table, instead of Forwarder&.

Actions #11

Updated by Junxiao Shi over 8 years ago

20150817 conference call approves design in note-10.

Actions #12

Updated by Junxiao Shi over 8 years ago

In commit:ec82530b4e1deaf51104a87b2ea013e13bbf6821, reviewer suggests renaming RegionSet to NetworkRegions, with the following reasons:

  1. "producer region" is a little bit general term. I would at least add "network" in the middle.
    here there is no context and "producer region name" can mean "North America", "Los Angeles", "UCLA", "backbone", etc.

  2. call it just NetworkRegions
    set is even worse, as it has suggestion that it is a set. It can be other data structure.
    at least one of our tables is using plural case and for table it is expected to have plural meaning.

I agree with the first statement.

I disagree with the second statement.
It's bad to name a container as the plural form of the item it contains, because the difference between an item and a container is not obvious enough.
For example, in .NET Framework, a collection of XmlAttribute is named XmlAttributeCollection, and a collection of AccessControlEntry is named AccessControlList.

However, I agree that set should not be used because this table is not necessarily an std::set.

I propose the following candidate names: NetworkRegionList, NetworkRegionTable, ProducerRegionList, ProducerRegionTable.

Actions #13

Updated by Junxiao Shi over 8 years ago

  • % Done changed from 50 to 80
Actions #14

Updated by Junxiao Shi over 8 years ago

20150821 conference call decides to call the table NetworkRegionTable.

Actions #15

Updated by Junxiao Shi over 8 years ago

On commit:472726cc684d50488f0fd27e2114e274bba1928d, reviewer has pointed out that Interest::getLink and Interest::getSelectedDelegation can throw exceptions if the Interest packet is malformed, although the @throw declaration of these functions indicates that they can throw only if the field is missing.

I think the solution is:

  1. Add the missing condition to Interest::getLink and Interest::getSelectedDelegation as a @throw declaration.
  2. Ensure the entire Interest is well-formed, before entering any forwarding pipelines.
  3. To avoid the overhead of parsing Link multiple times when Interest::getLink is called multiple times, a unique_ptr<Link> field should be stored within Interest class.

In item 2, it's important that the packet format validation is completed before entering any forwarding pipelines, because forwarding shouldn't process a malformed packet at all.
Partially processing a packet, only to find it malformed later and drop it later in the pipeline, is not only expensive (eg. ContentStore lookup), but also complex (eg. how to undo the PIT entry? violates NFD design goal "simplicity").

The short-term solution is: in Forwarder::onInterest function, call Interest::getLink and Interest::getSelectedDelegation after checking the field exists.

The long-term solution is: in Interest::wireDecode and Data::wireDecode, introduce a "deep parsing" mode which parses every sub-element and ensures they are correct; NFD face system should use "deep parsing" mode.

Actions #16

Updated by Junxiao Shi over 8 years ago

At 20150827 conference call, Alex didn't disagree with note-15 solution, but also offered with an alternate solution:

A malformed Link can be ignored (as if it doesn't exist) during packet processing.

I disagree with this alternate solution.

A malformed packet indicates that the sender has violated the protocol.
Attempting to serve such packets wastes network resources, and may cause security concerns.

Note that this discussion is only about a field that is recognized but malformed.
Unrecognized fields are out of scope.

Actions #17

Updated by Junxiao Shi over 8 years ago

20150901 conference call approves note-15 solution.

We also decide to change the return type of Interest::getLink to const Link& which references the Link object in unique_ptr.

Actions #18

Updated by Junxiao Shi over 8 years ago

  • Blocked by Feature #3155: Ensure packet is well-formed before entering pipelines added
Actions #19

Updated by Junxiao Shi over 8 years ago

  • Description updated (diff)
Actions #20

Updated by Alex Afanasyev over 8 years ago

What is the status for NetworkRegionTable management (do we have an issue for that)?

Actions #21

Updated by Junxiao Shi over 8 years ago

  • Blocks Feature #3159: NetworkRegionTable configuration option added
Actions #22

Updated by Junxiao Shi over 8 years ago

  • Description updated (diff)
  • Status changed from In Progress to Resolved

Code is merged, but I still need to update devguide.

Actions #23

Updated by Junxiao Shi over 8 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 80 to 100

devguide is updated in nfd-docs:commit:040c5bd7ef76562cbb13dec78532a27c869be08b

Actions #24

Updated by Junxiao Shi over 7 years ago

  • Blocks Feature #3664: Incoming Nack pipeline: consider Link during FIB lookup added
Actions

Also available in: Atom PDF