NFD » NDN Specifications

Please send proposal to ndn@ mailing list for spec discussion.

I'm also mad at this problem these days when trying out ndnfs-port.

Agree with the proposal. We've had similar problems with the routing status page. The status data was published without a freshness period. This worked with NDNx, but when we switched to NFD the interpretation was changed, so the Interests always retrieved the status data from the caches. We changed the code so it's now working. However, I expect many (new) developers will not put freshness period in their data explicitly and discover that they end up always getting cached data even when they want to retrieve new data.

We discovered a related question during code review.

The existing protocol says:

If an exact duplicate of a stale Data arrives, the effect is the same as if the stale Data had not been present. In particular, the Data in the store is no longer stale.

And https://gerrit.named-data.net/3694 patchset4 changes the wording to:

When the exact replicate of the "stale" Data packet, carrying positive FreshnessPeriod value, is inserted into content store, content store SHOULD remove "stale" bit.

However, is the the correct design?

Davide's opinion:

When would such a scenario happen anyway? The only scenario that I can think of is: a node has a stale Data packet in its CS, an interest with MustBeFresh arrives and is forwarded (since it cannot be satisfied by the stale cached Data), eventually this Interest brings back the same exact Data from another node's CS, where it hadn't become stale yet. If this Data is allowed to "refresh" the FreshnessPeriod of the locally cached Data, there's the risk that it will never become really stale.

I think that, if strategy follows FIB and FIB has a single path, "exact replicate of the stale Data" can only come from the producer, not from a CS. Consider this topology:

P---A---B---C
        |
        D

1. C expresses an Interest, and P returns a Data with limited FreshnessPeriod, which is cached at A and B.
2. D expresses an Interest for the same Data with MustBeFresh. If the cached Data at B is stale, the cached Data at A must be stale as well, because FreshnessPeriod does not change per hop, and the Data enters A's CS earlier than entering B's CS.
3. If B receives an exact replicate of the Data, it must be coming from P. P, as the producer, is permitted to assert the Data is not stale for the next FreshnessPeriod duration.

Junxiao Shi wrote:

I think that, if strategy follows FIB and FIB has a single path, "exact replicate of the stale Data" can only come from the producer, not from a CS.

You may be right, IF the FIB has a single path. That's a pretty strong assumption. Why are you excluding multipath scenarios?

I believe Davide still had some concerns about the merged changes. @Davide is this still the case?

Reply to note-12:

The merged commit fulfills the requirements specified in issue title. Any other concerns should be reported as a separate issue.