<div dir="ltr">Awesome! Nice work :)<div><br></div><div>Wentao<br><br><div class="gmail_quote">On Sat, Apr 4, 2015 at 10:24 AM Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>For what it's worth – the initial project that clued us into this need is (I think) the first public art sculpture using NDN. :)  </div>
<div><br>
</div>
<div>This object is supposed to stay up-and-running on its own for the next year or so.  (I've mentioned it before but it officially launched last night.)  We are using NDN to fetch bus arrival data, and when we upgrade to Raspberry PI 2 controllers, will switch
 back to NDN for lighting control (changed to UDP for now to get refresh rates needed). </div>
<div><br>
</div>
<div><img src="cid:0965EEAB-17F6-45CC-B467-7FE4BA4D683C" type="image/png"></div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span>
<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>Jeff Burke <<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>><br>
<span style="font-weight:bold">Date: </span>Wed, 25 Mar 2015 18:04:16 +0000<br>
<span style="font-weight:bold">To: </span>Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.edu</a>" <<a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.edu</a>>, "Horn, Alex" <<a href="mailto:nano@remap.UCLA.EDU" target="_blank">nano@remap.UCLA.EDU</a>>,
 John DeHart <<a href="mailto:jdd@seas.wustl.edu" target="_blank">jdd@seas.wustl.edu</a>></div></span></div><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><span><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"><br>
<span style="font-weight:bold">Subject: </span>Re: [Nfd-dev] Behavior of "on demand" faces to applications<br>
</div></span></div><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><span>
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Hi Junxiao,</div>
<div><br>
</div>
<div>Thanks, this is very helpful. (@AlexH: We should probably implement this for all the permanent routes on borges & memoria.)</div>
<div><br>
</div>
<div>I have added an <a href="http://redmine.named-data.net/issues/2696" target="_blank">issue</a> in redmine to document face creation/destruction behavior – this is something that should be easily understood by anyone deploying a multi-node application in a semi-real-world
 environment. </div>
<div><br>
</div>
<div>As Lan points out in issue <a href="http://redmine.named-data.net/issues/2491" target="_blank">
2491</a>, not having "permanent" faces creates deployment challenges.   </div>
<div><br>
</div>
<div>I would suggest that the NFD team make permanent face support (for any underlying transport) a high priority for implementation, and easily selected—even perhaps the default—in routes created by 'nfdc register'.     </div>
<div><br>
</div>
<div>Given that we try to use UDP wherever possible (so as not to create an invisible crutch of ordering and reliability for apps deployed on top), support for permanent UDP faces is actually higher for us than TCP, though both are used. </div>
<div><br>
</div>
<div>A few use cases on our end: </div>
<div><br>
</div>
<div>- We have a few Raspberry PIs deployed in an outdoor installation, which connect to each other via a wire and use NDN over UDP to communicate. One has a WiFi connection to the campus network, and uses NDN over TCP to get data from a remote process.    Occasionally,
 we restart one of the NFDs and not the other.  Also, occasionally, we have brief dropouts of wireless connectivity to the campus network.   In both cases, we lose the NDN faces and lose uptime of something that's supposed to run continuously.  While  Junxiao's
 approach provides a solution, it involves running additional components, etc.   Given that we are running out of time on that project, I'm probably going to remove NDN communication because of this and some performance issues on the PIs.  Better would be if
 NFD itself handled intermittent connectivity losses more robustly as proposed in the "permanent face".  </div>
<div><br>
</div>
<div>- We have now a small number of persistent services (which we are trying to increase) that are designed to run unattended for long periods of time. (e.g., the ndnfs publisher for ndn content).  This would be very useful to have.  While the TCP connections
 are more stable, we are always upgrading / restarting versions of NFD, adding routes, etc.  So a low-overhead way of having permanent routes would be extremely helpful. </div>
<div><br>
</div>
<div>The "permanent" behavior seems to be the most typically desired for any manually registered routes – whether for the lifetime of the NFD daemon (in the nfdc-created case) or the lifetime of an application process (in the app-created case).    I hope this
 can be considered for implementation soon...</div>
<div><br>
</div>
<div>Thanks!!</div>
<div>Jeff</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<div><br>
</div>
<div><br>
</div>
<span>
<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" target="_blank">shijunxiao@email.arizona.edu</a>><br>
<span style="font-weight:bold">Date: </span>Sat, 21 Mar 2015 14:04:41 -0700<br>
<span style="font-weight:bold">To: </span>Jeff Burke <<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>><br>
<span style="font-weight:bold">Cc: </span>Alex Afanasyev <<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>>, "Gusev, Peter" <<a href="mailto:peter@remap.ucla.edu" target="_blank">peter@remap.ucla.edu</a>>, "<a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.edu</a>"
 <<a href="mailto:nfd-dev@lists.cs.ucla.edu" target="_blank">nfd-dev@lists.cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Nfd-dev] Behavior of "on demand" faces to applications<br>
</div>
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div dir="ltr">Hi Jeff
<div><br>
</div>
<div><font size="4">A</font></div>
<div>A <i>persistent</i> TCP face is considered <i>failed</i> when TCP connection is broken. There's no built-in way to re-establish the connection and routes.<br>
</div>
<div>#<a href="http://redmine.named-data.net/issues/2491" target="_blank">2491</a> will provide the concept of
<i>permanent</i> face which does exactly that: TCP connection is re-established after it's broken, and FaceId remains unchanged. This is still in early idea stage.</div>
<div><br>
</div>
<div>The workaround used by <a href="http://yoursunny.com/p/ndn6/" target="_blank">
NDN6.TK</a> is:</div>
<div>
<ol>
<li>use <a href="https://github.com/yoursunny/ndn6-tools/blob/master/facemon.md" target="_blank">
facemon</a> to monitor face destroy events</li><li>pipe the output of facemon to an awk script</li><li>in the awk script, if the face to the uplink router is destroyed, invoke <font face="monospace,monospace">
nfdc register</font> to re-establish the face and register static routes</li></ol>
<div>I'm attaching the awk script for reference.</div>
</div>
<div><br>
</div>
<div><span style="font-size:large">B</span><br>
</div>
<div>A <i>persistent</i> UDP unicast face is considered <i>failed</i> when it receives an ICMP error. During the restart of remote NFD, if local NFD sends a UDP packet and gets back an ICMP error, the face will be destryoed; if local NFD doesn't send during
 this period, the face should be intact.</div>
<div>As I remember, this behavior dates back to May 2014, and hasn't been significantly changed since then.</div>
<div><br>
</div>
<div>You may use iptables to block incoming ICMP PortUnreachable error to avoid face getting destroy.</div>
<div>Otherwise, the workaround above is also effective.</div>
<div><br>
</div>
<div>Yours, Junxiao<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Mar 21, 2015 at 1:44 PM, 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>Alex / nfd folks, </div>
<div><br>
</div>
<div>We're going to make sure local connections are through unix sockets whenever available. </div>
<div><br>
</div>
<div>Two quick related questions.  Feel free to send a RTFM pointer: </div>
<div><br>
</div>
<div>#A - </div>
<div>- Is there a built-in way for "persistent" routes to get re-established if the TCP connection goes down?   I interpreted your original description to mean this is not the default behavior. </div>
<div><br>
</div>
<div>#B - </div>
<div>In the case of UDP faces, what happens in this situation: </div>
<div><br>
</div>
<div>1. nfdc is used to register (with a local NFD) a persistent UDP face for a remote NFD</div>
<div>2. The face is created successfully</div>
<div>3. The remote NFD is killed and then restarted</div>
<div><br>
</div>
<div>Is the intended behavior that the face created in #1 is still up after #3?   (And, has this been the case in all versions of NFD?  I am debugging a problem on an installation running an older version of NFD on the Raspberry PI.)</div>
<div><br>
</div>
<div>Thanks!</div>
<div>Jeff</div>
<div><br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</span></div>
</div>
_______________________________________________ Nfd-dev mailing list <a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">
Nfd-dev@lists.cs.ucla.edu</a> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a> </blockquote>
</span></div>

______________________________<u></u>_________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/<u></u>mailman/listinfo/nfd-dev</a><br>
</blockquote></div></div></div>