Task #4717

Clarify FacePersistency semantics

Added by Davide Pesavento over 1 year ago. Updated over 1 year ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


During the 2018-08-15 NDN Platform call, while discussing #3521, it emerged that we don't have a clear idea of the meaning of FACE_PERSISTENCY_PERSISTENT and FACE_PERSISTENCY_PERMANENT, and that the behavior provided by persistent faces (close on any socket error) might not be very useful after all. Moreover, the current implementations of permanent TCP and UDP transports do not seem to behave in the same way when the local IP address changes, and it's unclear what the "right" behavior should be.

We should clarify the exact meaning and expected behavior of FACE_PERSISTENCY_PERSISTENT and FACE_PERSISTENCY_PERMANENT, and fix the implementation if needed.

Related issues

Related to NFD - Feature #3521: Netdev-bound facesIn Progress




Updated by Davide Pesavento over 1 year ago


Updated by Junxiao Shi over 1 year ago

  • Assignee set to Davide Pesavento

20181119 call discussed this topic. Davide agreed to post a summary and then close this issue.


Updated by Davide Pesavento over 1 year ago

  • We reached consensus on removing the current persistent semantics from all faces and keep only on-demand and permanent.
    • We did not discuss whether to (a) redefine persistent with permanent semantics and remove FACE_PERSISTENCY_PERMANENT, or (b) remove FACE_PERSISTENCY_PERSISTENT and use permanent in its place.
  • Alex pointed out that current persistent semantics can be useful when an end host moves from one testbed site to another.
    • We decided that ndn-autoconfig can take care of this by re-running the autoconfig procedure periodically (and/or when connectivity changes) and creating any new faces needed to connect to the new testbed router; the face connected to the previous testbed router can either be closed or set to DOWN state (note: NFD mgmt protocol doesn't currently support setting the face state).
  • On the question of how to handle local IP address changes in permanent faces (i.e. TCP and UDP unicast), we decided to adopt the new local IP address when the face "reconnects".
    • Rationale: currently these face types are created with local IP == ANY ( or [::]), so it's expected that they'll take whatever address is configured on the interface used by the OS to send out packets (according to the IP routing table).
    • If needed, a future extension may allow users to specify a local FaceUri when creating a TCP or UDP face, in a fully backward-compatible way. When a local FaceUri is specified in this way, the face remains tied to that IP address even if it disappears from the system.

Also available in: Atom PDF