Project

General

Profile

Actions

Feature #5277

open

Remove persistent faces

Added by Junxiao Shi over 1 year ago. Updated 10 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Faces
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
15.00 h

Description

As discussed in 20181119 NFD call, persistent semantics shall be removed from all face types, keeping only on-demand and permanent levels.


Related issues 1 (0 open1 closed)

Related to NFD - Task #4717: Clarify FacePersistency semanticsClosedDavide Pesavento

Actions
Actions #1

Updated by Junxiao Shi over 1 year ago

  • Related to Task #4717: Clarify FacePersistency semantics added
Actions #2

Updated by Junxiao Shi 10 months ago

  • Status changed from New to In Progress
  • Assignee set to Junxiao Shi

https://gerrit.named-data.net/c/NFD/+/7271 changes nfdc face create command defaults from persistent to permanent.
This is the first step of deprecating and removing persistent semantics.

Actions #3

Updated by Davide Pesavento 10 months ago

  • Category set to Faces

I'd like to see a clear and comprehensive design before we move forward with any changes under this issue. The design should address the remaining outstanding questions in #4717 (which was closed prematurely IMHO).

Actions #4

Updated by Junxiao Shi 10 months ago

My plan is, progressively:

  1. nfdc defaults to creating permanent faces, but can still create persistent faces if requested.
  2. nfdc only creates permanent faces. This applies to all subcommands that could create faces.
  3. FaceMgmt deprecates persistent. Default persistency in ControlParameters becomes permanent.
  4. NFD interprets persistent as permanent.
  5. ndn-cxx deprecates persistent.
  6. ndn-cxx removes persistent. NFD rejects persistent
Actions #5

Updated by Davide Pesavento 10 months ago

I believe there are a few more unresolved design questions stemming from #4717, including:

  • As pointed out in #4717#note-4, Unix faces resemble persistent faces in their behavior, although we currently classify them as on demand. If we want to fix this inconsistency in the future (as a separate issue), we may need a third persistency type. (though I admit I don't love the name "persistent" for this case)
  • There may be some implications for ndn-autoconfig that haven't been fully fleshed out yet. (see #4717#note-3)
  • If permanent faces are expected to update their local IP address, which could change when the face reconnects, then someone needs to actually verify that this is indeed the behavior. If it's not, we need to fix the implementation.
    • As a corollary, if the local IP changes, will the LocalUri also change? What are the implications of this?
  • Another question I have personally: what's the relationship/difference with netdev-bound faces? (this may not be relevant here, but it's worth mentioning)
Actions #6

Updated by Junxiao Shi 10 months ago

As pointed out in #4717#note-4, Unix faces resemble persistent faces in their behavior, although we currently classify them as on demand. If we want to fix this inconsistency in the future (as a separate issue), we may need a third persistency type. (though I admit I don't love the name "persistent" for this case)

It's real simple: ondemand=incoming, permanent=outgoing.
Unix socket face would be ondemand always.

There may be some implications for ndn-autoconfig that haven't been fully fleshed out yet. (see #4717#note-3)

The autoconfig tool may choose to close old faces and open new ones.

If permanent faces are expected to update their local IP address, which could change when the face reconnects, then someone needs to actually verify that this is indeed the behavior. If it's not, we need to fix the implementation.

If device IP changes, the autoconfig tool can close old faces and open new ones.

As a corollary, if the local IP changes, will the LocalUri also change? What are the implications of this?

LocalUri contains local IP so that it must change.

Another question I have personally: what's the relationship/difference with netdev-bound faces? (this may not be relevant here, but it's worth mentioning)

There's no interest in implementing that.

Actions

Also available in: Atom PDF