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

Sat Apr 4 15:20:03 PDT 2015

Awesome! Nice work :)

Wentao

On Sat, Apr 4, 2015 at 10:24 AM Burke, Jeff <jburke at remap.ucla.edu> wrote:

>
>  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).
>
>
>
>
>   From: Jeff Burke <jburke at remap.ucla.edu>
> Date: Wed, 25 Mar 2015 18:04:16 +0000
> To: Junxiao Shi <shijunxiao at email.arizona.edu>
> Cc: "nfd-dev at lists.cs.ucla.edu" <nfd-dev at lists.cs.ucla.edu>, "Horn, Alex"
> <nano at remap.UCLA.EDU>, John DeHart <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>
> Date: Sat, 21 Mar 2015 14:04:41 -0700
> To: Jeff Burke <jburke at remap.ucla.edu>
> Cc: Alex Afanasyev <alexander.afanasyev at ucla.edu>, "Gusev, Peter" <
> peter at remap.ucla.edu>, "nfd-dev at lists.cs.ucla.edu" <
> 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>
> 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
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>  _______________________________________________
> Nfd-dev mailing list
> 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/1b4eb0ff/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: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150404/1b4eb0ff/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2015-04-04 10.19.38.png
Type: image/png
Size: 294223 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150404/1b4eb0ff/attachment-0001.png>