[Nfd-dev] [Ndn-app] NDN-RTC poke Data to CS

[Dave Oran (oran)]

While pushing data out into a cache isn’t necessarily dangerous if the cache is *truly* local, I am frankly quite nervous about this as a precedent. Why? Because “local” is an incredibly slippery concept which ought to be completely specified before going down this path. At a minimum, I’d suggest that “local” not mean “the face is on the same box as the app”, but that either:
a) the cache and the app are in exactly the same security container or
b) the cache and app are mutually authenticated by means outside of NDN, and that the cache is protected by authorization machinery against pollution or poisoning by an application.

I’ll also note that if the goal here is to protect against an app that produces data and then the box it’s running on crashes or gets partitioned form the network, the approach of local faces won’t do the trick. It may however permit data to survive an application crash or exit.

Clearly the alternative of having a fast and robust repo is superior to opening up the can of worms above. As a general comment, I’m detecting a bit more expediency here than I’m comfortable with. 

However, if we really need to seed caches, let me suggest we step back and try to design an alternative approach. If the goal is simply to ensure data is available in advance of interests arriving to either reduce delay or provide robustness against app crash or box crash or network partition (I suspect the vehicular guys might be the ones interested in partition) there are alternatives that might work a whole lot better.

One that occurs to me on just a few minutes thought is to issue an interest for the data at the same time you publish the data, and have machinery to route the interest explicitly to the cache you want to fill. I’ll point out that explicit interest routing might have other uses as well.

Just thinking out loud here.

On Mar 22, 2014, at 9:40 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Dear folks
> 
> The design is:
> Incoming Data pipeline decides whether a Data is unsolicited or not.
> A function decides whether an unsolicited Data CAN be admitted.
> Currently, this function returns true if incoming face is local.
> Replacing this function allows for alternate behaviors.
> This function SHOULD NOT be part of CS policy (which governs the replacement of cached Data). It is a policy in forwarding, not in CS.
> If allowed by the function in step 2, the Data is given to CS.
> CS policy decides whether to admit the Data based on available space, and also decides which Data to evict in case CS is full.
> 
> Yours, Junxiao
> _______________________________________________
> Ndn-app mailing list
> Ndn-app at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app

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