[Nfd-dev] Close NFD backdoor

[Yingdi Yu]

Hi Jeff,

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 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. 

Yingdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140909/ffb19e75/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140909/ffb19e75/attachment.bin>