[Nfd-dev] Close NFD backdoor

[Alex Afanasyev]

On Sep 9, 2014, at 10:29 PM, Burke, Jeff <jburke at remap.UCLA.EDU> wrote:

> 
> One could imagine different configurable strategies for the MemoryContentCache depending on the way the application uses FreshnessPeriod. I'm not sure exactly the end goal of this discussion? 
> 
> I haven't been closely following all the messages but I think Dave Oran alluded to the fact that just having FreshnessPeriod may not be enough. This has come up in the past in other contexts and may be worth discussing.  
> 
> You state "My understanding about this is that FreshnessPeriod is used by end producer to tell intermediate routers (including local nfd) how long a data packet should stay in a content store."
> 
> This is fair, but imagine three different consumer applications for the same ndnrtc streams, all of which have different opinions about what content from a single publisher is relevant to be in a content store -
> 1. "real-time" live-playback (current app) - only needs freshest data (within some buffer time period)
> 2.  Fixed ten-second expletive-removing delay consumer – can have a fetching buffer that's significantly larger (though not the full seven seconds) than the above, but otherwise is "real-time" 
> 3. digital video recorder style playback – may have much larger delays, and fetch content that may be minutes, days, hours older than the freshest content while other consumers are also watching the freshest content.
> 
> Given these three consumers for a single publisher of live video, how should FreshnessPeriod be used to the best effect / appropriately?

In my mind, the only purpose for FreshnessPeriod is to control on producer-side how often it wants to see request for "fresh" data.  Also, consumers should send requests for "fresh" data only when they really need to get up to date knowledge about "current" data.  For me, this implies that FreshnessPeriod (at least for some key frames or meta-data) should be set to something that producer thinks it can handle and it is an acceptable "real-time delay" (say 10-100ms).   "Normal" data should be requested without any selectors set and it is perfectly acceptable for any content store to serve "stale" data.  This applies to all content stores on the path and content store on a producer machine/in-app store.

So, I don't see any complication in the above three cases.  For the first two "real-time" cases, consumers would from time to time request fresh data to synchronize playback, but majority requests would need not to be related to freshness (no MustBeFresh selector). For the last case, none of the interests should have the selector and FreshnessPeriod is completely irrelevant for those.

---
Alex


> J. 
> 
> From: Yingdi Yu <yingdi at CS.UCLA.EDU>
> Date: Mon, 8 Sep 2014 11:29:56 -0700
> To: Jeff Thompson <jefft0 at remap.ucla.edu>
> Cc: "<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>, "ndn-app at lists.cs.ucla.edu" <ndn-app at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] Close NFD backdoor
> 
>> Hi JeffT,
>> 
>> On Sep 8, 2014, at 2:53 AM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
>> 
>>> The NDN-RTC video conferencing app uses the MemoryContentCache in-app storage. It keeps data in the cache based on the data packet's FreshnessPeriod.
>>> http://named-data.net/doc/ndn-ccl-api/memory-content-cache.html
>>> 
>>> You say "content store is aware of FreshnessPeriod of data packets, but an in-app storage should not."  Why should the in-app storage not be aware of the FreshnessPeriod?
>> 
>> In the NDN-TLV spec, the definition of FreshnessPeriod says "Note that the stale data is still valid data; the expiration of FreshnessPeriod only means that the producer may have produced newer data." My understanding about this is that FreshnessPeriod is used by end producer to tell intermediate routers (including local nfd) how long a data packet should stay in a content store. The end producer is the only one who knows and can decide whether a data packet is valid or not. And the in-memory storage contains data packets that are treated as valid by end producer.
>> 
>> For example, producer A generates a data packet "/a/b/c" with 10-second FreshnessPeriod. If "/a/b/c" is put into the MemoryContentCache, the packet will be removed from the cache after 10 seconds, and the producer A will have to generate the same data packet again even if the producer A still takes "/a/b/c" as valid. With the in-memory storage, the packet will never be removed until the producer generates a new valid data packet to replace "/a/b/c". And "/a/b/c" will be obsolete by the new data packet.
>> 
>> Yingdi
>> 
>> _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140910/a220b157/attachment.html>