https://redmine.named-data.net/https://redmine.named-data.net/favicon.ico?14759811232018-08-20T15:29:41ZNDN project issue tracking systemNFD - Task #4717: Clarify FacePersistency semanticshttps://redmine.named-data.net/issues/4717?journal_id=238742018-08-20T15:29:41ZDavide Pesavento
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-2 priority-2 priority-default" href="/issues/3521">Feature #3521</a>: Netdev-bound faces</i> added</li></ul> NFD - Task #4717: Clarify FacePersistency semanticshttps://redmine.named-data.net/issues/4717?journal_id=243602018-11-23T11:47:13ZJunxiao Shi
<ul><li><strong>Assignee</strong> set to <i>Davide Pesavento</i></li></ul><p>20181119 call discussed this topic. Davide agreed to post a summary and then close this issue.</p>
NFD - Task #4717: Clarify FacePersistency semanticshttps://redmine.named-data.net/issues/4717?journal_id=244162018-12-09T17:33:58ZDavide Pesavento
<ul></ul><ul>
<li>We reached consensus on removing the current <em>persistent</em> semantics from all faces and keep only <em>on-demand</em> and <em>permanent</em>.
<ul>
<li>We did not discuss whether to (a) redefine <em>persistent</em> with permanent semantics and remove <code>FACE_PERSISTENCY_PERMANENT</code>, or (b) remove <code>FACE_PERSISTENCY_PERSISTENT</code> and use <em>permanent</em> in its place.</li>
</ul></li>
<li>Alex pointed out that current persistent semantics can be useful when an end host moves from one testbed site to another.
<ul>
<li>We decided that <code>ndn-autoconfig</code> 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 (<em>note:</em> NFD mgmt protocol doesn't currently support setting the face state).</li>
</ul></li>
<li>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".
<ul>
<li>Rationale: currently these face types are created with local IP == ANY (<code>0.0.0.0</code> or <code>[::]</code>), 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).</li>
<li>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.</li>
</ul></li>
</ul>
NFD - Task #4717: Clarify FacePersistency semanticshttps://redmine.named-data.net/issues/4717?journal_id=272152021-03-14T22:14:05ZDavide Pesavento
<ul></ul><p>Eric correctly points out that Unix faces are always created with <em>on-demand</em> persistency but don't have the close-on-idle behavior described in <a class="wiki-page" href="https://redmine.named-data.net/projects/nfd/wiki/FaceMgmt">FaceMgmt</a>.</p>
<p>The current behavior is correct but classifying Unix faces as <em>on-demand</em> is inconsistent with the definition. Their behavior is actually closer to that of <em>persistent</em> faces, although the plan described above would remove that persistency level.</p>
NFD - Task #4717: Clarify FacePersistency semanticshttps://redmine.named-data.net/issues/4717?journal_id=279422023-07-29T17:23:06ZJunxiao Shi
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-2 priority-2 priority-default" href="/issues/5277">Feature #5277</a>: Remove persistent faces</i> added</li></ul> NFD - Task #4717: Clarify FacePersistency semanticshttps://redmine.named-data.net/issues/4717?journal_id=279442023-07-29T17:23:13ZJunxiao Shi
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li></ul>