Project

General

Profile

Actions

Feature #3836

closed

localhop scope definition

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

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

100%

Estimated time:

Description

ScopeControl rev2 defines localhop Scope as:

Interest packets under prefix ndn:/localhop are restricted by these rules:

  • Interest can come from a local face or a non-local face.
  • If PIT entry has at least one InRecord from a local face, it can be forwarded to local faces and non-local faces.
  • If PIT entry has all InRecords from non-local faces, it can only be forwarded to local faces.
  • PIT entry can be satisfied by Data from any source.

It's recommended to change the rules as:

  1. If an Interest is received from a local face, it can be forwarded to a non-local face.
  2. If an Interest is received from a non-local face, it cannot be forwarded to a non-local face.
  3. In either case the Interest can be forwarded to a local face.
Actions #1

Updated by Junxiao Shi about 8 years ago

I agree with the new rules, which is much cleaner.

However, thinking about forwarding pipelines, it becomes clear why I came up the current rules two years ago:

  1. When an Interest is passed to a strategy for forwarding, the strategy can either forward the Interest immediately, or use a timer to forward the Interest later (NCC is a strategy that does this).
  2. When a strategy decides to forward an Interest, it invokes the outgoing Interest pipeline. The arguments include the PIT entry and the outgoing face, but do not indicate which incoming Interest is being forwarded. In other words, once an incoming Interest is passed to the strategy, the rest pipelines operate on PIT entry granularity.
  3. The outgoing Interest pipeline checks whether the strategy violates the localhop scope. This check is supposed to use the new rules, but that's not implementable, and thus we end up with the current intuitive rules.
  4. Finally, the outgoing Interest pipeline picks a Nonce. This step just picks the last incoming Nonce without considering scope.

Unrelated to scope rules, the current outgoing Interest pipeline has another problem: it picks the outgoing InterestLifetime and Nonce.
The recommendation in #1966-7 suggests that the choice of InterestLifetime and Nonce should be given to the strategy, at least in some cases.

Also, I recall that Beichuan has an argument about "forwarding does not need to understand name semantics" vs "localhop rule": the operator can install a strategy that enforces localhop rules at /localhop prefix, so that forwarding itself does not need to understand those rules, and it becomes a network policy decision in the form of strategy choice.
I agree with this argument.

Based on these three points, I think we should:

  • adopt the new rules as a recommendation to strategy designs
  • remove localhop enforcement in forwarding
  • revise outgoing Interest pipeline to let strategy decide which InterestLifetime and Nonce to use; recommendation for strategy is to use the incoming Interest's InterestLifetime and Nonce when forwarding an Interest, and #1966-7 when processing a Nack-Duplicate
  • implement the new rules in daemon/fw/pit-algorithm.hpp as a free function that can be used in strategies
Actions #2

Updated by Junxiao Shi about 8 years ago

Posted on behalf of Beichuan:

The problem in implementing the correct rules is that the outgoing pipeline doesn’t know the incoming face of the Interest being forwarded. Then we should tackle this problem head-on instead of spinning around and involving many other things.

You propose to let strategy enforce localhop. Does the strategy know the incoming face of a packet? If yes, it can work. Otherwise it doesn’t.

Assuming the answer is yes. However, moving localhop support from pipeline to every strategy will likely to take long time and becomes another never-ending task.

Why not fixing the interface between strategy and outgoing pipeline so that the pipeline has the incoming face information to enforce to rules? This will be a much easier task.

The wiki page should be updated now. The old rules are not design rules; they’re implementation techniques that don’t achieve the design goal of /localhop scope. They should be replaced by the new rules. Then whether our code implements the rules correctly is an issue separate from the design.

Actions #3

Updated by Junxiao Shi about 8 years ago

The problem in implementing the correct rules is that the outgoing pipeline doesn’t know the incoming face of the Interest being forwarded. Then we should tackle this problem head-on instead of spinning around and involving many other things.

Adding a "incoming face" parameter to outgoing Interest pipeline is also going to cause many other problems: the definition of "incoming face" is unclear when a strategy retries an Interest in response to a Nack.

The "many other things" are necessary. They are directly need to implement #1966-7 recommendation.

You propose to let strategy enforce localhop. Does the strategy know the incoming face of a packet? If yes, it can work. Otherwise it doesn’t.

Yes, it's an argument to every trigger.

Assuming the answer is yes. However, moving localhop support from pipeline to every strategy will likely to take long time and becomes another never-ending task.

Any changes to outgoing Interest pipeline require a change in every strategy.
Thus, moving localhop rules into every strategy will take as much time.

Why not fixing the interface between strategy and outgoing pipeline so that the pipeline has the incoming face information to enforce to rules? This will be a much easier task.

No. It's strategy's responsibility to check the rules. The actual implementation is in violatesScope function shared among strategies.
The outgoing Interest pipeline contains a secondary check to ensure strategy doesn't make a policy-violating decision.

Actions #4

Updated by Junxiao Shi about 8 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

ScopeControl rev3 has the new rules. I'll create separate issues for engineering work.

Actions #5

Updated by Junxiao Shi about 8 years ago

#1756 and #3841 cover the implementation changes.

Actions #6

Updated by Junxiao Shi about 8 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF