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

[Dave Oran (oran)]

Abject confusion.

I thought one of the deep tenets of NDN was that it would be infeasible to inject unsolicited data into the network, thus eliminating all forms of flooding attacks other than of Interest messages.

Snooping a broadcast wire is a special case where the data was in fact solicited (and the interest could have been snooped too).

Sorry, but I clearly have not been privy to any of the backstory here, so it kind of hit me out of the blue.

DaveO.

On Mar 19, 2014, at 2:39 AM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>> wrote:

Hi Jeff,

Even in the first release, there is no problem with unsolicited data caching for **local** faces (unix socket and tcp connection to localhost address), which should be sufficient for any stand-alone application, including ndnrtc.

I'm kind of blanking right now on how ndnrtc relates to browser (is it inside browser and can do local connection or javascript will to websockets for that).  If it is websocket, then the websocket "proxy" (and/or special face inside NFD---just in case, this will not be in the first release) can be made "local", so unsolicited caching can be enabled.

In any case, as Beichuan pointed out, Junxiao described the behavior that will be in the first release, which will have exactly one hard-coded caching policy for the content stored.  Next releases would have policies that can be adjusted per node.

---
Alex

On Mar 18, 2014, at 10:44 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi Beichuan,

Thanks for the further explanation.

We would like to run the ndnrtc on NFD as an initial test – should we look for this functionality in the repo or try to provide it in the library?  (or both?)

thanks,
Jeff


From: "bzhang at cs.arizona.edu<mailto:bzhang at cs.arizona.edu>" <bzhang at cs.arizona.edu<mailto:bzhang at cs.arizona.edu>>
Date: Tue, 18 Mar 2014 22:38:31 -0700
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>>, Peter Gusev <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>, <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC poke Data to CS

In my opinion, caching unsolicited data or not should be the choice of each individual node; nothing in the architecture or protocol prevents that.

What Junxiao said is probably what the first release of NFD will have.

Beichuan

On Mar 18, 2014, at 7:57 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter
In seminar slides you mention that the RTC application in browser may poke Data to a remote forwarder.
I want to inform you that NFD will not admit any unsolicited Data from non-local face. NFD will admit unsolicited Data from local face, but they will be the first to get evicted when CS is full.
You should insert Data into a  repository instead.
Yours, Junxiao
_______________________________________________
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

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

_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140319/8a7a333f/attachment.html>