<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 19, 2014, at 10:03 AM, Dave Oran (oran) <<a href="mailto:oran@cisco.com">oran@cisco.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div><br class="Apple-interchange-newline">On Mar 19, 2014, at 12:46 PM, Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="font-family: Calibri, sans-serif; font-size: 14px;"><i>Test question: how long do you think it will be before somebody jiggers the TCP connection to home on a remote box :-)</i></div><div style="font-family: Calibri, sans-serif; font-size: 14px;"><i><br></i></div><div style="font-family: Calibri, sans-serif; font-size: 14px;">Probably already happening. :) </div><div style="font-family: Calibri, sans-serif; font-size: 14px;"><br></div><div style="font-family: Calibri, sans-serif; font-size: 14px;"><i>One thing you said below did confuse me: "<font face="Calibri,sans-serif">you don't know how long the frames will really stay in the content store.” Don’t all data objects have a timeout? Why would you not set the timeout to the playout deadline established by the application? Or are you concerned about eviction too soon as opposed to them hanging around too long? </font></i></div><div style="font-family: Calibri, sans-serif; font-size: 14px;"><font face="Calibri,sans-serif"><br></font></div><div><font face="Calibri,sans-serif">Yes, this is all true. But as I understand it the content store gives no guarantee of what content will persist if it receives more objects than it can hold. For now, this is not an issue but when there are many apps moving content through the same store on a given node, we can't count on objects persisting. This is why a repo is probably ultimately the right place for this data to go, as you suggest. It has the added benefit of providing content archival, too.</font></div><div><font face="Calibri,sans-serif"><br></font></div></div></blockquote>that’s what I suspected. I’d like to get involved in discussions around this. We are busy designing and building our wire-speed cache, and face the problem of intelligent CS eviction with a very small cycle budget at the scale we are running. Having enough information (e.g. desired holding time as well as maximum useful lifetime), in a form that can drive an eviction algorithm that avoids cache thrashing a pretty big part of our design analysis right now.</div></blockquote><div><br></div><div>Hello Dave,</div><div>In our implementation we do not have a periodic cache cleanup as it is done in CCNx. CS entries are evicted during the insertion. I expect good performance because it is cheap constant time operation, but we don’t have firm numbers right now.</div><div><br></div><div>Ilya</div><br><blockquote type="cite"><div style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Thanks again,</div><div style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">DaveO.</div><div style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><font face="Calibri,sans-serif"></font></div><div>Jeff</div><div style="font-family: Calibri, sans-serif; font-size: 14px;"><br></div><div style="font-family: Calibri, sans-serif; font-size: 14px;"><br></div><span id="OLK_SRC_BODY_SECTION" style="font-family: Calibri, sans-serif; font-size: 14px;"><div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);"><span style="font-weight: bold;">From:<span class="Apple-converted-space"> </span></span>"Dave Oran (oran)" <<a href="mailto:oran@cisco.com">oran@cisco.com</a>><br><span style="font-weight: bold;">Date:<span class="Apple-converted-space"> </span></span>Wed, 19 Mar 2014 14:52:29 +0000<br><span style="font-weight: bold;">To:<span class="Apple-converted-space"> </span></span>Jeff Burke <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>><br><span style="font-weight: bold;">Cc:<span class="Apple-converted-space"> </span></span>Alex Afanasyev <<a href="mailto:alexander.afanasyev@ucla.edu">alexander.afanasyev@ucla.edu</a>>, "<a href="mailto:ndn-app@lists.cs.ucla.edu">ndn-app@lists.cs.ucla.edu</a>" <<a href="mailto:ndn-app@lists.cs.ucla.edu">ndn-app@lists.cs.ucla.edu</a>>, "Gusev, Peter" <<a href="mailto:peter@remap.ucla.edu">peter@remap.ucla.edu</a>>, "<a href="mailto:bzhang@cs.arizona.edu">bzhang@cs.arizona.edu</a>" <<a href="mailto:bzhang@cs.arizona.edu">bzhang@cs.arizona.edu</a>>, "<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>" <<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>><br><span style="font-weight: bold;">Subject:<span class="Apple-converted-space"> </span></span>Re: [Ndn-app] [Nfd-dev] NDN-RTC poke Data to CS<br></div><div><br></div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">OK, thanks for the clarification. Test question: how long do you think it will be before somebody jiggers the TCP connection to home on a remote box :-)<div><br></div><div>Among the implementation options you list below, it seems a fast Repo would be the best way forward, given that the lack of a fast repo would like cause more hacks to migrate either up to the application or down to the forwarder.</div><div><br></div><div>One thing you said below did confuse me: "<font face="Calibri,sans-serif"><span style="font-size: 14px;">you don't know how long the frames will really stay in the content store.” Don’t all data objects have a timeout? Why would you not set the timeout to the playout deadline established by the application? Or are you concerned about eviction too soon as opposed to them hanging around too long? </span></font></div><div><font face="Calibri,sans-serif"><span style="font-size: 14px;"><br></span></font></div><div><div><div>On Mar 19, 2014, at 10:42 AM, Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;"><div><br></div><div>Dave,</div><div><br></div><div>Sorry, this is a specific case that indeed requires some backstory:</div><div><br></div><div>- We are only talking about local content injection – i.e., from app to its local daemon.</div><div><br></div><div>- This is a "feature" of NDNx/CCNx used in applications like our rtc implementation to provide a local buffer for publishing. Frames get pushed out as soon as they are captured, and the app itself doesn't have to worry about buffering them. The main downside is actually that you don't know how long the frames will really stay in the content store.</div><div><br></div><div>- We do something similar (dumping frames as captured) in video playout with a repository. </div><div><br></div><div>- I'm only concerned with preserving support for this in the initial NFD release so we can quickly test the application as is. There are three other solutions that seem better: 1) implement an application-side buffer in the library; we will do this soon; 2) provide an authenticated mechanism to control how the local daemon handles such pushed data; 3) have a fast local repo implementation that can be used for the same purpose.</div><div><br></div><div>But there's no unsolicited content injection into the network.</div><div><br></div><div>Jeff</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);"><span style="font-weight: bold;">From:<span class="Apple-converted-space"> </span></span>"Dave Oran (oran)" <<a href="mailto:oran@cisco.com">oran@cisco.com</a>><br><span style="font-weight: bold;">Date:<span class="Apple-converted-space"> </span></span>Wed, 19 Mar 2014 11:06:31 +0000<br><span style="font-weight: bold;">To:<span class="Apple-converted-space"> </span></span>Alex Afanasyev <<a href="mailto:alexander.afanasyev@ucla.edu">alexander.afanasyev@ucla.edu</a>><br><span style="font-weight: bold;">Cc:<span class="Apple-converted-space"> </span></span>Jeff Burke <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>>, "<a href="mailto:ndn-app@lists.cs.ucla.edu">ndn-app@lists.cs.ucla.edu</a>" <<a href="mailto:ndn-app@lists.cs.ucla.edu">ndn-app@lists.cs.ucla.edu</a>>, "Gusev, Peter" <<a href="mailto:peter@remap.ucla.edu">peter@remap.ucla.edu</a>>, "<a href="mailto:bzhang@cs.arizona.edu">bzhang@cs.arizona.edu</a>" <<a href="mailto:bzhang@cs.arizona.edu">bzhang@cs.arizona.edu</a>>, "<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>" <<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>><br><span style="font-weight: bold;">Subject:<span class="Apple-converted-space"> </span></span>Re: [Ndn-app] [Nfd-dev] NDN-RTC poke Data to CS<br></div><div><br></div><div><div dir="auto"><div>Abject confusion.</div><div><br></div><div>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.</div><div><br></div><div>Snooping a broadcast wire is a special case where the data was in fact solicited (and the interest could have been snooped too).</div><div><br></div><div>Sorry, but I clearly have not been privy to any of the backstory here, so it kind of hit me out of the blue.</div><div><br></div><div>DaveO.</div><div><br>On Mar 19, 2014, at 2:39 AM, "Alex Afanasyev" <<a href="mailto:alexander.afanasyev@ucla.edu">alexander.afanasyev@ucla.edu</a>> wrote:<br><br></div><blockquote type="cite"><div>Hi Jeff,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>---</div><div>Alex</div><br><div><div>On Mar 18, 2014, at 10:44 PM, Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><font face="Calibri,sans-serif">Hi Beichuan,</font></div><div><font face="Calibri,sans-serif"><br></font></div><div><font face="Calibri,sans-serif">Thanks for the further explanation.</font></div><div><font face="Calibri,sans-serif"><br></font></div><div><font face="Calibri,sans-serif">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?)</font></div><div><font face="Calibri,sans-serif"><br></font></div><div><font face="Calibri,sans-serif">thanks,</font></div><div><font face="Calibri,sans-serif">Jeff</font></div><div><font face="Calibri,sans-serif"><br></font></div><div style="font-family: Calibri, sans-serif; font-size: 14px;"><br></div><span id="OLK_SRC_BODY_SECTION" style="font-family: Calibri, sans-serif; font-size: 14px;"><div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);"><span style="font-weight: bold;">From:<span class="Apple-converted-space"> </span></span>"<a href="mailto:bzhang@cs.arizona.edu">bzhang@cs.arizona.edu</a>" <<a href="mailto:bzhang@cs.arizona.edu">bzhang@cs.arizona.edu</a>><br><span style="font-weight: bold;">Date:<span class="Apple-converted-space"> </span></span>Tue, 18 Mar 2014 22:38:31 -0700<br><span style="font-weight: bold;">To:<span class="Apple-converted-space"> </span></span>Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>><br><span style="font-weight: bold;">Cc:<span class="Apple-converted-space"> </span></span>"<a href="mailto:ndn-app@lists.cs.ucla.edu">ndn-app@lists.cs.ucla.edu</a>" <<a href="mailto:ndn-app@lists.cs.ucla.edu">ndn-app@lists.cs.ucla.edu</a>>, Peter Gusev <<a href="mailto:peter@remap.ucla.edu">peter@remap.ucla.edu</a>>, <<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>><br><span style="font-weight: bold;">Subject:<span class="Apple-converted-space"> </span></span>Re: [Nfd-dev] NDN-RTC poke Data to CS<br></div><div><br></div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">In my opinion, caching unsolicited data or not should be the choice of each individual node; nothing in the architecture or protocol prevents that.<div><br></div><div>What Junxiao said is probably what the first release of NFD will have. </div><div><br></div><div>Beichuan</div><div><br></div><div><div>On Mar 18, 2014, at 7:57 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Peter</div><div dir="ltr">In seminar slides you mention that the RTC application in browser may poke Data to a remote forwarder.</div><div dir="ltr">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.</div><div dir="ltr">You should insert Data into a repository instead.</div><div dir="ltr">Yours, Junxiao</div>_______________________________________________<br>Nfd-dev mailing list<br><a href="mailto:Nfd-dev@lists.cs.ucla.edu">Nfd-dev@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br></blockquote></div><br></div></div>_______________________________________________ Nfd-dev mailing list<span class="Apple-converted-space"> </span><a href="mailto:Nfd-dev@lists.cs.ucla.edu">Nfd-dev@lists.cs.ucla.edu</a><span class="Apple-converted-space"> </span><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a></span></div>_______________________________________________<br>Nfd-dev mailing list<br><a href="mailto:Nfd-dev@lists.cs.ucla.edu">Nfd-dev@lists.cs.ucla.edu</a><br><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br></blockquote></div><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br><span>Ndn-app mailing list</span><br><span><a href="mailto:Ndn-app@lists.cs.ucla.edu">Ndn-app@lists.cs.ucla.edu</a></span><br><span><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app</a></span><br></blockquote></div></div></span></div></blockquote></div><br></div></div></div></span></div></blockquote></div><br style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">_______________________________________________</span><br style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Ndn-app mailing list</span><br style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="mailto:Ndn-app@lists.cs.ucla.edu" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Ndn-app@lists.cs.ucla.edu</a><br style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app" style="font-family: Helvetica; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app</a></blockquote></div><br></body></html>