[Nfd-dev] [Ndn-app] Close NFD backdoor -- PLEAE LEAVE IT OPEN

Giovanni Pau gpau at CS.UCLA.EDU
Tue Sep 9 17:32:47 PDT 2014


Dear All, 

This for the V2V case represents a problem, we relay a lot on caching unsolicited content to achieve higher delivery rate. The V2V environment is so harsh that you can’t miss any opportunity to grab a content that may be useful in the future.  

I would be more incline to find a compromise based on a configuration parameter (i.e. this becomes a configuration issue per face) or to enable unsolicited content caching if there are some trust mechanism, however for us is really essential to keep this feature alive.

Thanks 
Giovanni



==========================
It had long since come to my attention that people of accomplishment rarely sat back and let things happen to them. They went out and happened to things. 

- Leonardo da Vinci 
==========================




On Sep 9, 2014, at 4:17 AM, Dave Oran (oran) <oran at cisco.com> wrote:

> 
> 
> ___________________________
> iDevice - please excuse typos.
> 
> On Sep 8, 2014, at 6:21 PM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:
> 
>> 
>> On Sep 8, 2014, at 12:58 PM, Dave Oran (oran) <oran at cisco.com> wrote:
>> 
>>> I don’t mean to hijack this thread, but it seems that the architecture needs two cache timers, not one.
>>> 
>>> One is an Expiry timer after which the data is no longer considered valid (and hence should not be returned from the cache if an interest arrives)
>> 
>> I am not sure if it is always possible for a data producer to predict the time when the data will become invalid.
> If not the producer, then who? All data kept outside an application's private (and possibly permanent) store has a validity period, if not shorter then at least no longer than the lifetime of the key that signed it.
> 
>> Take DNS as an example, the authoritative server may never know when one of the records will be changed.
>> 
> Wrong analogy. A DNS Authoritative server is like a repo, a producer is in effect the application that updated the DNS.
> 
>> Yingdi 
> _______________________________________________
> Ndn-app mailing list
> Ndn-app at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app





More information about the Nfd-dev mailing list