<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;">
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
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?)</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>"Dave Oran (oran)" <<a href="mailto:oran@cisco.com">oran@cisco.com</a>><br>
<span style="font-weight:bold">Date: </span>Sun, 23 Mar 2014 20:05:04 +0000<br>
<span style="font-weight:bold">To: </span>Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>><br>
<span style="font-weight:bold">Cc: </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>>, "<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>Re: [Nfd-dev] [Ndn-app] 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;">
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:
<div>a) the cache and the app are in exactly the same security container or</div>
<div>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.</div>
</div>
</div>
</span>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<b><br>
</b></div>
<div><b><font face="Calibri,sans-serif">[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.)</font></b></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>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.</div>
<div><br>
</div>
<div>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. </div>
</div>
</div>
</span>
<div><br>
</div>
<div><b><font face="Calibri,sans-serif">[jb] Yes; a fast repo seems the best solution for our use cases so far. </font></b></div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div><br>
</div>
<div>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.
<div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</div>
</span>
<div><br>
</div>
<div><span style="font-family: Calibri, sans-serif; font-weight: bold;">[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. </span></div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>
<div>
<div><br>
</div>
<div>Just thinking out loud here.</div>
<div><br>
<div>
<div>On Mar 22, 2014, at 9:40 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">
<div class="gmail_extra">Dear folks</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">The design is:</div>
<div class="gmail_extra">
<ol>
<li>Incoming Data pipeline decides whether a Data is unsolicited or not.<br>
</li><li>A function decides whether an unsolicited Data CAN be admitted.<br>
<ul>
<li>Currently, this function returns true if incoming face is local.</li><li>Replacing this function allows for alternate behaviors.</li><li>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.</li></ul>
</li><li>If allowed by the function in step 2, the Data is given to CS.<br>
CS policy decides whether to admit the Data based on available space, and also decides which Data to evict in case CS is full.</li></ol>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Yours, Junxiao</div>
</div>
_______________________________________________<br>
Ndn-app mailing list<br>
<a href="mailto:Ndn-app@lists.cs.ucla.edu">Ndn-app@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
_______________________________________________ Nfd-dev mailing list <a href="mailto:Nfd-dev@lists.cs.ucla.edu">
Nfd-dev@lists.cs.ucla.edu</a> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev">
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a> </span>
</body>
</html>