Project

General

Profile

Feature #4871

autoconfig: try multiple routers from NDN-FCH

Added by Junxiao Shi about 1 year ago. Updated 7 months ago.

Status:
Code review
Priority:
Normal
Assignee:
Category:
Tools
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
6.00 h

Description

In ndn-autoconfig, request multiple routers from NDN-FCH service, and try each one until finding a working router.


Files

IMG_20190501_151919Z.jpg (182 KB) IMG_20190501_151919Z.jpg 5309,4 Procedure logic Junxiao Shi, 05/01/2019 08:21 AM

History

#1

Updated by Davide Pesavento about 1 year ago

  • Status changed from New to Code review
  • Target version set to v0.7
#2

Updated by Junxiao Shi 12 months ago

In 5309,2, the logic after obtaining a list of HUBs is:

  1. Canonize a FaceUri. If canonization fails, go to step 5.
  2. Send a face creation command. If face creation fails, go to step 5.
  3. Register prefixes toward the HUB.
  4. Declare success and abort these steps.
  5. If the list contains another HUB, try the next HUB. Otherwise, declare failure.

First problem with this logic is: UDP face creation always succeeds, even if the HUB is down or unreachable.
Prefix registration toward a UDP face would not fail either.
Thus, Procedure must test the HUB works: send an Interest that the HUB would respond with either Data or Nack, then read face counters to check RX counter is non-zero.

Second problem: if none of the HUBs returns from one stage works, the program should try the next stage.
For example, after failing NDN-FCH, the next stage would be GuessFromIdentityName.

#3

Updated by Teng Liang 11 months ago

Junxiao Shi wrote:

In 5309,2, the logic after obtaining a list of HUBs is:

  1. Canonize a FaceUri. If canonization fails, go to step 5.
  2. Send a face creation command. If face creation fails, go to step 5.
  3. Register prefixes toward the HUB.
  4. Declare success and abort these steps.
  5. If the list contains another HUB, try the next HUB. Otherwise, declare failure.

First problem with this logic is: UDP face creation always succeeds, even if the HUB is down or unreachable.
Prefix registration toward a UDP face would not fail either.
Thus, Procedure must test the HUB works: send an Interest that the HUB would respond with either Data or Nack, then read face counters to check RX counter is non-zero.

Agreed.

Second problem: if none of the HUBs returns from one stage works, the program should try the next stage.
For example, after failing NDN-FCH, the next stage would be GuessFromIdentityName.

Once a stage fails, it tries next stage. GuessFromIdentifyName has been added as the 4th stage since the previous commit.

#4

Updated by Junxiao Shi 11 months ago

In https://gerrit.named-data.net/5309 patchset4, Procedure type has incorrect logic.

5309,4 Procedure logic

  • "A" and "B" represent stages.
  • "x" and "y" represent HUB URIs found by a stage.
  • Brown indicates implemented logic.
  • Red indicates corrections.
#5

Updated by Davide Pesavento 11 months ago

Junxiao Shi wrote:

First problem with this logic is: UDP face creation always succeeds, even if the HUB is down or unreachable.

True. However, this is already the case today: the FCH stage always succeeds (unless the backend service itself is unreachable I guess), so the subsequent stages are never used. It's not a new problem introduced by this change. Therefore I'm not convinced that solving it belongs to this issue.

Thus, Procedure must test the HUB works: send an Interest that the HUB would respond with either Data or Nack, then read face counters to check RX counter is non-zero.

This sounds quite complicated and fragile. One potential alternative is to create faces towards all discovered hubs, and let the forwarding plane deal with nexthop selection as it should. This might even prove more reliable in some cases.

#6

Updated by Junxiao Shi 11 months ago

One potential alternative is to create faces towards all discovered hubs, and let the forwarding plane deal with nexthop selection as it should.

This would break prefix propagation, because /localhop/nfd/rib/register would point to multiple remote routers and the readvertise module would only receive one response. Hence, this solution would be blocked by #3142 #3143.

#7

Updated by Teng Liang 11 months ago

Junxiao Shi wrote:

One potential alternative is to create faces towards all discovered hubs, and let the forwarding plane deal with nexthop selection as it should.

This would break prefix propagation, because /localhop/nfd/rib/register would point to multiple remote routers and the readvertise module would only receive one response. Hence, this solution would be blocked by #3142 #3143.

I agree with Davide's proposal, because detecting whether a face works should not be part of this procedure, since forwarding plane or "link" layer is a better place to handle it.
@Junxiao, why prefix propagation cannot work with multiple remote routers?

#8

Updated by Junxiao Shi 11 months ago

why prefix propagation cannot work with multiple remote routers?

You have multiple /localhop/nfd registrations. When you send a /localhop/nfd/rib/register command to propagate a prefix, you can receive no more than one response. Without receiving all responses, you can't determine whether prefix propagation has succeeded.

#9

Updated by Teng Liang 11 months ago

You have multiple /localhop/nfd registrations. When you send a /localhop/nfd/rib/register command to propagate a prefix, you can receive no more than one response. Without receiving all responses, you can't determine whether prefix propagation has succeeded.

A local producer registers a prefix on a local NFD. The local NFD propagate this prefix to multiple connected gateways. These two steps are separate.

#10

Updated by Junxiao Shi 11 months ago

A local producer registers a prefix on a local NFD.

This step is unaffected.

The local NFD propagate this prefix to multiple connected gateways.

This step would not work if there are multiple /localhop/nfd registrations.

These two steps are separate.

Yes.

#11

Updated by Teng Liang 11 months ago

The local NFD propagate this prefix to multiple connected gateways.

This step would not work if there are multiple /localhop/nfd registrations.

What's the problem of handling this case, e.g., do registration for each gateway respectively?

#12

Updated by Junxiao Shi 8 months ago

What's the problem of handling this case, e.g., do registration for each gateway respectively?

See #3142 issue description.

#13

Updated by Davide Pesavento 7 months ago

  • Target version changed from v0.7 to v0.8

Also available in: Atom PDF