[Nfd-dev] Close NFD backdoor

[Burke, Jeff]

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?

J.

From: Yingdi Yu <yingdi at CS.UCLA.EDU<mailto:yingdi at CS.UCLA.EDU>>
Date: Mon, 8 Sep 2014 11:29:56 -0700
To: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>, "ndn-app at lists.cs.ucla.edu<mailto:ndn-app at lists.cs.ucla.edu>" <ndn-app at lists.cs.ucla.edu<mailto: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<mailto: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<mailto: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/73e9640f/attachment.html>