<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; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hi Junxiao,</div>
<div><br>
</div>
<div>Thanks! It would be great to summarize such things in a design document somewhere rather than relying on the mailing list traffic / issues... Has the team considered this? </div>
<div><br>
</div>
<div>One question: The approach suggested by these recommendations seems to be motivated by having the application's in-memory cache play the role of the content store... I'm not sure that necessarily they have the same goals. (I have to think about this
more.) For example, the app may just want to support a modest history (last few seconds of video, for example), while the forwarder may have its own goals that result in caching more or less than this. So is what you're describing on the level of an architectural
recommendation or simply the best approach we have for now... ? </div>
<div><br>
</div>
<div>Jeff</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<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>Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>><br>
<span style="font-weight:bold">Date: </span>Wed, 1 Apr 2015 10:21:02 -0700<br>
<span style="font-weight:bold">To: </span>Jeff Burke <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>><br>
<span style="font-weight:bold">Cc: </span>"<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] Handling new content in app for pending interest in NFD<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div dir="ltr">
<div>Hi Jeff</div>
<div><br>
</div>
<div>The recommendation for "soft realtime app" is given below.</div>
<div>Please note that some features are not yet implemented, but the specifications are already approved.</div>
<div>Watch each listed feature for implementation progress.</div>
<div><br>
</div>
<div><br>
</div>
<div>The <b>forwarder MUST NOT cache unsolicited Data</b>, regardless of its origin.<br>
</div>
<div>Feature: <a href="http://redmine.named-data.net/issues/2181" target="_blank">http://redmine.named-data.net/issues/2181</a></div>
<div>Announcement: <a href="http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000605.html">http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000605.html</a></div>
<div><br>
</div>
<div>A soft realtime app MUST maintain an <b>in-memory storage</b>.</div>
<div>It MUST NOT rely on the forwarder to cache its Data, even if they are sent to the forwarder in response to an unexpired Interest.</div>
<div>The data structure is referred to as "in-memory storage" rather than "cache", because it SHOULD be fully managed by the app to keep all Data that the app wants to serve. It's not a cache where useful Data can be evicted.</div>
<div>Reason: the forwarder is free to evict any Data.</div>
<div><br>
</div>
<div>A soft realtime app SHOULD set <b>CachingPolicy=NoCache</b> in LocalControlHeader (or NDNLPv2 header) on a Data served from an in-memory storage.</div>
<div>The local forwarder ContentStore SHOULD NOT cache a Data with CachingPolicy=NoCache.</div>
<div>
<div>CachingPolicy field is not carried to remote forwarders, so that remote forwarders can still cache the Data. It avoids duplicate Data copies on localhost.</div>
</div>
<div>Protocol: <a href="http://redmine.named-data.net/projects/nfd/wiki/LocalControlHeader#CachingPolicy-feature">http://redmine.named-data.net/projects/nfd/wiki/LocalControlHeader#CachingPolicy-feature</a></div>
<div>Feature: <a href="http://redmine.named-data.net/issues/2183">http://redmine.named-data.net/issues/2183</a> <a href="http://redmine.named-data.net/issues/2185">http://redmine.named-data.net/issues/2185</a> <a href="http://redmine.named-data.net/issues/2184">http://redmine.named-data.net/issues/2184</a></div>
<div><br>
</div>
<div>A soft realtime app MAY maintain its PIT to <b>avoid sending unsolicited Data</b>.</div>
<div>When an app chooses not to maintain a PIT, sending unsolicited Data has no harmful effect.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Yours, Junxiao</div>
<br>
<div class="gmail_quote">On Wed, Apr 1, 2015 at 8:38 AM, Burke, Jeff <span dir="ltr"><<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div><br>
</div>
<div>Thanks for all of the discussion. I am not sure if I have been able to extract an answer to the original question I was asking. Let me try again with more information:</div>
<div><br>
</div>
<div>- The original question was intended to be only about a local NFD (for now).</div>
<div><span style="white-space:pre-wrap"></span></div>
<div>- The use case is a (soft) real-time application, like videoconferencing or streaming sensor data for interactive applications. Specifically, we have encountered the issue in 1) ndnrtc/<a href="https://github.com/remap/ndncon/" target="_blank">ndncon</a> for
videoconferencing and 2) ndn-opt, which streams data from <a href="http://openptrack.org/" target="_blank">OpenPTrack</a>, a person tracking system built on the robot operating system (ROS). </div>
<div><br>
</div>
<div>- In these use cases, consumers want to receive data with low latency, so they send interests intended to arrive before the time the data is produced, but not so long before that the Interests expire before corresponding data is produced. </div>
<div><br>
</div>
<div>- As they are born, samples are signed and put into a repository by the publisher. Currently these apps use an in-memory repo specific to the application, via the MemoryContentCache class provided by the NDN-CCL library. But this could just as well be
a repo outside the application.</div>
<div><br>
</div>
<div>- So, when Interests arrive, they go in the local NFD's PIT, and are forwarded to the application. We are interested in the case where the data is not born <i>yet</i>, so the publisher cannot respond to the Interest.</div>
<div><br>
</div>
<div>- Then, before the Interest expires from the local NFD's PIT, the corresponding data is born in the application and <i>should</i> be used to answer the Interest. But how does that data get back to the local forwarder? </div>
<div><br>
</div>
<div>- What should the application do? 1) Maintain its own PIT? 2) Or, push the data to the local NFD, letting it drop it if it doesn't satisfy anything. 3) Or, as we have previously discussed about the MemoryContentCache, do we need to consider a more
sophisticated interaction model between the application and the daemon's content store and/or PIT that reduces duplication of these capabilities in applications? </div>
<div><br>
</div>
<div>- For now, we have implemented an in-application PIT in ndnrtc. (I am not sure what method we ended up using in ndn-opt, perhaps the unsolicited data method.) </div>
<div><br>
</div>
<div>- Discussion on this topic will help inform what library support will be provided in the short term. (I don't think we want every application author to have to write a PIT, so am thinking in the short term we should provide one to complement the MemoryContentCache
class. But this is duplicating data structures and functionality in NFD – is that natural, or should we look to handle it through a different interaction with the local forwarder?) </div>
<div><br>
</div>
<div>Thanks,</div>
<div>Jeff</div>
<div><br>
</div>
</div>
</blockquote>
</div>
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Mar 30, 2015 at 10:28 AM, Burke, Jeff <span dir="ltr">
<<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div><br>
</div>
<div>Hi folks,</div>
<div><br>
</div>
<div>We are facing this scenario in a few applications:</div>
<div><br>
</div>
<div>1) Interest received by NFD, passed to an application</div>
<div>2) Application not able to respond to interest, so interest stays in NFD PIT</div>
<div>3) Some time passes, but not enough for the Interest to expire</div>
<div>4) Application generates data (e.g., from a sensor reading) that would answer the Interest in the NFD PIT</div>
<div><br>
</div>
<div>Question: How does app know to inform NFD it has the data after step 4, and how should it do that? </div>
<div><br>
</div>
<div>- In this type of app, should it push the data unsolicited to the NFD and let it decide if there is something to do? </div>
<div>- Is it recommended to implement an application-level PIT so the app is sure this data is solicited? (Why add <i>another</i> PIT?) </div>
<div><br>
</div>
<div>Thank you,</div>
<div>Jeff</div>
<div><br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>