[Nfd-dev] Behavior of "on demand" faces to applications

Sat Apr 4 10:24:17 PDT 2015

For what it's worth – the initial project that clued us into this need is (I think) the first public art sculpture using NDN. :)

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).

[cid:0965EEAB-17F6-45CC-B467-7FE4BA4D683C]

From: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Date: Wed, 25 Mar 2015 18:04:16 +0000
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Cc: "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>, "Horn, Alex" <nano at remap.UCLA.EDU<mailto:nano at remap.UCLA.EDU>>, John DeHart <jdd at seas.wustl.edu<mailto:jdd at seas.wustl.edu>>
Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications

Hi Junxiao,

Thanks, this is very helpful. (@AlexH: We should probably implement this for all the permanent routes on borges & memoria.)

I have added an issue<http://redmine.named-data.net/issues/2696> 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.

As Lan points out in issue 2491<http://redmine.named-data.net/issues/2491>, not having "permanent" faces creates deployment challenges.

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'.

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.

A few use cases on our end:

- 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".

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

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

Thanks!!
Jeff

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sat, 21 Mar 2015 14:04:41 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>, "Gusev, Peter" <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>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications

Hi Jeff

A
A persistent TCP face is considered failed when TCP connection is broken. There's no built-in way to re-establish the connection and routes.
#2491<http://redmine.named-data.net/issues/2491> will provide the concept of permanent 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.

The workaround used by NDN6.TK<http://yoursunny.com/p/ndn6/> is:

  1.  use facemon<https://github.com/yoursunny/ndn6-tools/blob/master/facemon.md> to monitor face destroy events
  2.  pipe the output of facemon to an awk script
  3.  in the awk script, if the face to the uplink router is destroyed, invoke nfdc register to re-establish the face and register static routes

I'm attaching the awk script for reference.

B
A persistent UDP unicast face is considered failed 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.
As I remember, this behavior dates back to May 2014, and hasn't been significantly changed since then.

You may use iptables to block incoming ICMP PortUnreachable error to avoid face getting destroy.
Otherwise, the workaround above is also effective.

Yours, Junxiao

On Sat, Mar 21, 2015 at 1:44 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:
Alex / nfd folks,

We're going to make sure local connections are through unix sockets whenever available.

Two quick related questions.  Feel free to send a RTFM pointer:

#A -
- 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.

#B -
In the case of UDP faces, what happens in this situation:

1. nfdc is used to register (with a local NFD) a persistent UDP face for a remote NFD
2. The face is created successfully
3. The remote NFD is killed and then restarted

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.)

Thanks!
Jeff

_______________________________________________ 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150404/2105cfbf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2015-04-04 10.19.38.png
Type: image/png
Size: 294223 bytes
Desc: Screenshot 2015-04-04 10.19.38.png
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150404/2105cfbf/attachment.png>