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

[Burke, Jeff]

Please see below.   (Quick related question about the repo:  is the current repo that Shuo is working on integrated into this two week NFD test?  Would it be possible to hear some observations on how it is performing relative to ndnrtc data rates discussed in a previous email?)

From: "Dave Oran (oran)" <oran at cisco.com<mailto:oran at cisco.com>>
Date: Sun, 23 Mar 2014 20:05:04 +0000
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Cc: "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>>, "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>>
Subject: Re: [Nfd-dev] [Ndn-app] NDN-RTC poke Data to CS

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.

[jb] Yes, we've already started to see that this notion of "local" can get a little messy in the context of the browser support we've been working with, which uses a remote websockets proxy to talk to an ndnd.  The proxy is "local" to the daemon but the app is not really... this is probably an artifact of the current design that would go away, but it came up pretty quickly so it will probably do so again.  (For example,  it's unclear whether each browser tab's security container will include the local host or just the remote.)

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.

[jb] Yes; a fast repo seems the best solution for our use cases so far.

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.

[jb] Junxiao has pointed out this approach as well and it should also work in the short term.  We wish for some guarantees about persistence of the data in the content store, though, that don't come along with it unless there are other hooks provided.

Just thinking out loud here.

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

Dear folks

The design is:

  1.  Incoming Data pipeline decides whether a Data is unsolicited or not.
  2.  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.
  3.  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<mailto:Ndn-app at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app

_______________________________________________ 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/20140325/ab18de2e/attachment.html>