NFD

Isn't this issue blocked by 2991 instead of related to?

Because we will need the ControlParameter change to send the persistency attribute

Answer to note-5:

No. As long as the protocol is defined, both the client side and the server side can be developed in parallel.

Maybe I miss understood what is needed for this feature.

Shouldn't the change to solve this issue be made in this function by adding the parameter of persistency to the ControlParameter object?

void
Nfdc::FaceIdFetcher::startFaceCreate(const ndn::util::FaceUri& canonicalUri)
{
  ControlParameters parameters;
  parameters.setUri(canonicalUri.toString());

  m_controller.start<FaceCreateCommand>(parameters,
                                        [this] (const ControlParameters& result) {
                                          succeed(result.getFaceId());
                                        },
                                        bind(&FaceIdFetcher::onFaceCreateError, this, _1, _2,
                                             "Face creation failed"));
}

Because if that is the solution the ControlParameter need to be integrated before starting

We just merged commit that adds persistency to the ControlParameters, so this task can start.

In Gerrit there is a comment saying that the management files. Is it the task #2991 that should change these files?

Joao, I don't have a strong preference to separate issues into different commits. However, I will not disagree with Junxiao's desire to keep them separate. One thing that makes the other issue more complex is a test case (I will try to help with this).

does one need to first create a permanent face, and then register the route through the same face URI?

Yes. The operator can also use FaceId in the register command.

The order between create and register commands is arbitrary. A face implicited created by register command is persistent, and it can be upgraded to permanent by a create command with -P flag.

Any reason not to have a shortcut that lets the -P argument be passed to the register command too?

Implicit face creation is necessary for register command because if the operator has to create a persistent face then register a route, it's possible for the face to fail before the register command succeeds.

However, this is unnecessary for permanent faces, because a permanent face can never fail.

Adding -P to register command unnecessarily complicates logic.

From Jeff Burke:

I'd offer that from the user perspective, generally, it'd be beneficial to have slightly more complicated internal logic than to complicate the process for the end user or require what seems to be different semantics in this potentially quite common case. (The semantics of being able to do "create" after "register" is a little confusing – it's more of an "upgrade" or "modify" at that point than create.)

In all of our practical deployments, we will switch to using permanent UDP faces to try to minimize any need for manual intervention or watchdogs to recreate the route after interruptions. So having a single step consistent with typical registration but with an additional argument is preferred to two commands.

Either way, this detail should be in the developer's guide, and you might consider a log message that confirms the "upgrade" of the face more explicitly. The following certainly says it "succeeded" but is a little opaque, because from a user's perspective, it wasn't "creating" the face, but changing it's type. Also, the log message has no mention/confirmation of its "permanent" status.

jdisplay1:ndn jburke$ nfdc create -P udp4://spurs.cs.ucla.edu
...
1442849017.332018 WARNING: [FaceTable] Trying to add existing face id=266 to the face table
Face creation succeeded: ControlParameters(FaceId: 266, Uri: udp4://131.179.196.46:6363, )

Perhaps at face creation, the log should output the same details that are in nfd-status?

faceid=266 remote=udp4://131.179.196.46:6363 local=udp4://0.0.0.0:6363 counters={in={839i 8482d 10582387B} out={109830i 442d 12639710B}} non-local permanent point-to-point

From Jeff Burke:

I'd offer that from the user perspective, generally, it'd be beneficial to have slightly more complicated internal logic than to complicate the process for the end user or require what seems to be different semantics in this potentially quite common case. (The semantics of being able to do "create" after "register" is a little confusing – it's more of an "upgrade" or "modify" at that point than create.)

+1

Either way, this detail should be in the developer's guide, and you might consider a log message that confirms the "upgrade" of the face more explicitly. The following certainly says it "succeeded" but is a little opaque, because from a user's perspective, it wasn't "creating" the face, but changing it's type. Also, the log message has no mention/confirmation of its "permanent" status.

Yeah we can/should improve the logic, so that we don't try to re-add an existing face, but just change its persistency setting.

Are there any conditions where permanent faces should not attempt to recover transport failures? It appears that some cases are not handled. Two examples:
1) Change in IP address of the default NIC caused by, for example, changing WiFi networks.
2) Restart of remote NFD.

Seems like both of these should be recoverable, assuming that there is still IP connectivity to the remote hub (in the case of #1) and the remote NFD comes up properly (#2), but this hasn't been my experience recently.

If these should be recovered in the current version, I'll doublecheck and work on replicating the issue.

Davide Pesavento wrote:

From Jeff Burke:

I'd offer that from the user perspective, generally, it'd be beneficial to have slightly more complicated internal logic than to complicate the process for the end user or require what seems to be different semantics in this potentially quite common case. (The semantics of being able to do "create" after "register" is a little confusing – it's more of an "upgrade" or "modify" at that point than create.)

+1

Either way, this detail should be in the developer's guide, and you might consider a log message that confirms the "upgrade" of the face more explicitly. The following certainly says it "succeeded" but is a little opaque, because from a user's perspective, it wasn't "creating" the face, but changing it's type. Also, the log message has no mention/confirmation of its "permanent" status.

Yeah we can/should improve the logic, so that we don't try to re-add an existing face, but just change its persistency setting.

+1

Or maybe provide a way to create a permanent face when registering prefix?

Peter Gusev wrote:

Or maybe provide a way to create a permanent face when registering prefix?

Yes. My +1 above was because (1) in general I agree with Jeff's sentiment, and (2) more specifically I'd support adding -P to the register command. I suggest filing a separate ticket for this feature.

Jeff Burke wrote:

Are there any conditions where permanent faces should not attempt to recover transport failures? It appears that some cases are not handled. Two examples:

1) Change in IP address of the default NIC caused by, for example, changing WiFi networks.

This scenario is probably not handled (yet). Currently we re-initialize only the multicast faces when connectivity changes (i.e. interface or address added/removed/changed).

2) Restart of remote NFD.

This should be handled gracefully by the permanent face, but please note that the implementation of #2989 is "minimal" so we might have missed some cases.

If these should be recovered in the current version, I'll doublecheck and work on replicating the issue.

Yes please open a ticket for each issue.