NFD

While the issue was discovered with NLSR, NLSR is not way needed to reproduce the problem. One machine is enough:

1. Start NFD and nrd

2. Register some route through a UDP face toward some existing machine on the network that doesn't run NFD and doesn't firewall ICMP. In my case I did:

   nfdc register /example/prefix udp://131.179.196.44
   

   This results in the following nfd-status output

   Faces:
     ...
     faceid=10 remote=udp4://131.179.196.44:6363 local=udp4://131.179.196.220:6363 counters={in={0i 0d} out={0i 0d}}
     ...
   
   FIB:
     ...
     /example/prefix nexthops={faceid=10 (cost=0)}
     ...
   

3. Run ndn-tlv-peek for /example/prefix data

   ndn-tlv-peek /example/prefix/some-data
   

Expectation: no data retrieved and no changes to nfd-status output

Actual: no data retrieved, but UDP face is destoyed

The following is excerpt from nfd log related to the efent:

...
1404237094.527198 WARNING: [UdpFace] [id:10,endpoint:131.179.196.220:6363] Receive operation failed: Connection refused
1404237094.527287 DEBUG: [UdpFace] closeSocket  131.179.196.220:6363
1404237094.527345 DEBUG: [UdpChannel] afterFaceFailed: 131.179.196.44:6363
...
1404237094.530164 INFO: [FaceTable] Removed face id=10 remote=udp4://131.179.196.44:6363 local=udp4://131.179.196.220:6363

Just to add more details. Here tcpdump for the event:

10:51:34.526552 ARP, Request who-has 131.179.196.44 (00:30:48:da:16:c4) tell 131.179.196.220, length 28
10:51:34.526807 ARP, Reply 131.179.196.44 is-at 00:30:48:da:16:c4, length 46
10:51:34.526825 IP 131.179.196.220.6363 > 131.179.196.44.6363: UDP, length 38
10:51:34.527043 IP 131.179.196.44 > 131.179.196.220: ICMP 131.179.196.44 udp port 6363 unreachable, length 36

I'm not sure whether ignoring ICMP unreachable is the right thing to do.

Tunnel Authentication protocol #1285 requires UdpFace to periodically send out a refresh message, and a UdpFace is destroyed if refresh message is unanswered after several attempts.
This is similar to a broken TCP connection.

@Beichuan should clarify the intention of Tunnel Authentication regarding to this problem.

An alternative to ignoring ICMP (and which would be compatible with TCP faces) is for NLSR to subscribe to face status notifications. When it detects that created faces are destroyed, then it should re-create them (re-register prefix for towards the face).

Technically, face creation/re-creation is not exactly NLSR's job, but NLSR can do this anyways. At least for now.

You're right, face creation/recreation is not NLSR's job. This can be only a temporary solution. I don't understand the motivation for closing the face though (even if there's an error). It seems to only add overhead (for recreating the face).

I don't think it is logically correct to allow half-working face. That is, when one node on the network think it has face to another, while another node has no idea why it is receiving packets. At least such logic could apply to unicast UDP/TCP faces, which are kind of tunnels, which technically should have some sort of authentication in the future.

A different story is with multicast UDP/Ethernet Faces. They are not tunnels, there cannot have any authentication, and I don't think there is a similar problem with them anyways.

Perhaps one thing to consider is that the faces we are talking about for NLSR
can be considered permanently configured faces. We define these faces because
we are defining a network architecture. They aren't coming up because some
random node has appeared that wants to connect to us. If they go down, we
expect them to come back and we hope they come back very soon.

Would we rather have NFD understand that or have NLSR get the notification
that they have gone away and recreate them, then if the other end isn't
back yet, continue to cycle through the process of notification and recreation?

Even though tcp/dup faces are "permanently" configured in NLSR-sense, I see them as something like VPN connection (rather than GRE tunnels).

Also, there is another advantage of making NLSR (on in future some other helper process) to take care of managing faces to neighbors. This provides an opportunity to use any types of Faces, not just "permanent" UDP Faces. I don't necessarily see when it would be useful, but just in case.

The faces we are talking about here are really just links. They should be there, even if the status is down. Similar to what you find from ifconfig (the link is there, but the status can be down). I don't see why "another node has no idea why it is receiving packets" is a problem. It just delivers the packet to the application which knows how to handle it.

UDP tunnels are not regular links.
If NLSR wants to use links, configure GRE tunnels and communicate over Ethernet multicast.
Remember to set MTU=9000 to avoid packet loss.

UDP tunnels are subject to Tunnel Authentication protocol #1285.
I'm waiting for Beichuan to answer the question in note-4, before I can make any change to UDP tunnels.

I don't see any conflict between the authentication protocol and what I said. What I meant is that the face should not be automatically closed if there is a problem. The face should have a status to indicate whether it is currently working or not. But the faceid should be there until the creator explicitly disconnects it. This doesn't conflict with the protocol.

I wanted to raise this issue later, when starting to work on the vehicular faces, but since the discussion here seems to have become bigger and deeper, and some requirements are similar, I'll just say it here.
The basic assumption is that, in a vehicular network, connectivity is inherently intermittent, and we cannot destroy and recreate faces every time something doesn't work because of a transient network issue.

The linux networking stack has the concept of "up" and "down" for interfaces. When an interface is up it doesn't necessarily mean the connectivity works, but applications can still (try to) use it. In particular, interfaces can be up even if the underlying link is not present/working (whatever that means for the particular link layer).

Connections on the other hand can break and should be re-established by the interested party. However, while it's straightforward for TCP faces, the concept of connection doesn't have a clear meaning when applied to UDP faces. One could argue that the connection never breaks, since there's no connection in the first place.

So the question is: are NFD faces more akin to linux network interfaces or to TCP/IP connections?

As for a possible solution, would it make sense to have a "persistent" kind of UDP face that:

• is explicitly created by some process P
• does not react to send failures by committing suicide
• can be explicitly deleted by the same process P
• is automatically closed when P exits (for any reason)

?

TCP tunnels and UDP tunnels are similar to a VPN tunnel.
VPN solutions (eg. PPTP and OpenVPN) close the tunnel if there's a failure.
Therefore, TcpFace and UdpFace are connections, and they are subject to Tunnel Authentication protocol.

Multicast faces (Ethernet and UDP multicast) are similar to interface.

Junxiao Shi wrote:

TCP tunnels and UDP tunnels are similar to a VPN tunnel.
VPN solutions (eg. PPTP and OpenVPN) close the tunnel if there's a failure.
Therefore, TcpFace and UdpFace are connections, and they are subject Tunnel Authentication protocol.

Well I guess we're going to have to implement yet another type of face for our vehicular needs then.

Should this issue be rejected or we still want to do something here in the future?