[Nfd-dev] Proposed NDN spec change

Burke, Jeff jburke at remap.UCLA.EDU
Sun Jun 14 17:05:27 PDT 2015


Thanks for the explanation.  The proposed change makes sense to me, but just wanted to ask my original question again: Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly?  (Using only a default lets us have only one of these options.)

Thanks,
Jeff




On 6/10/15, 9:48 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:

>There are few cases that triggered this issue.  The most recent for me is key retrieval (with some assumptions and ndns model): the requester sends interests for key name + must be fresh selector, omitting the version number.  (Essentially, this allows certification chain to be updated (e.g., parent's key re-signed) without requiring resigning every single data packet.)  The assumption here is that this interest would periodically go to "authority" that will return the latest version of the data packet and verification would proceed.   Unfortunately, we didn't actually put FreshnessPeriod into certificate data packets (this will be fixed), which completely broke the assumption.  The data packet now becomes forever fresh and there is no way around it (except maybe using an exclude filter, which shouldn't be the primary mechanism for this purpose).
>
>Another issue that Junxiao recently encountered with ndnfs and I think I had something similar in the past with something else (I forgot what exactly triggered the original redmine issue).
>
>All issues I mentioned are related to discovery mechanism.  During discovery, only a partial name is known and there is a desire to contact "authority" for the data to get the latest knowledge.  On the other had, FreshnessPeriod (semi-ambiguously) defines how often this "authority" is willing to receive such interests and how frequently information is expected to change.
>
>---
>Alex
>
>> On Jun 10, 2015, at 9:27 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>> 
>> Alex,
>> 
>> Can you explain the motivating use case(s)?
>> Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly?
>> Thanks,
>> Jeff
>> 
>> 
>> 
>> 
>> On 6/10/15, 9:21 PM, "Nfd-dev on behalf of Alex Afanasyev" <nfd-dev-bounces at lists.cs.ucla.edu on behalf of alexander.afanasyev at ucla.edu> wrote:
>> 
>>> Dear all,
>>> 
>>> The current NDN spec defines that Data packets without FreshnessPeriod are considered always fresh ("data packet cannot be marked stale", http://named-data.net/doc/ndn-tlv/data.html#freshnessperiod).
>>> 
>>> This creates a problem for some applications that we are currently playing with and I would like the spec (and subsequently NFD implementation) to be changed to do the opposite:  when FreshnessPeriod is not specified, data packet should **never** be considered fresh.
>>> 
>>> We have discussed this issue in the past (http://redmine.named-data.net/issues/2440), but haven't finalized the decision.  If there are no objections, I would like to proceed with the change ASAP.
>>> 
>>> ---
>>> Alex
>>> 
>




More information about the Nfd-dev mailing list