[Nfd-dev] Close NFD backdoor

[Burke, Jeff]

From: Yingdi Yu <yingdi at cs.ucla.edu<mailto:yingdi at cs.ucla.edu>>
Date: Tue, 9 Sep 2014 23:20:45 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>, "<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 Jeff,

On Sep 9, 2014, at 10:29 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto: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 did not mean MemoryContentCache is wrong. In my own opinion, it is generally good to have app manage its own data packets. About how to manage the data, I think it is up to the application.

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?

I am not trying to define how to specify FreshnessPeriod. What I want to push for is an in-app data storage which can be explicitly managed by the app. Since the app is the producer of the data packet, so it should be able to determine the validity of a data packet without relying on FreshnessPeriod.

Yes, ok, I think we agree on that.  But I am still interested in figuring out FreshnessPeriod, too, separately. :)

Jeff


Yingdi

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