NLSR

When such destroy event can happen? I'm happy with this optimization, however I'm not convinced that it is general enough. Right now we may have knowledge that face is down because we are using tunnels. Without tunnels, there are only few cases when you will be able to know that the other side is not responding or something wrong is happening (e.g., somebody is disconnecting link from the router).

Alex Afanasyev wrote:

When such destroy event can happen? I'm happy with this optimization, however I'm not convinced that it is general enough. Right now we may have knowledge that face is down because we are using tunnels. Without tunnels, there are only few cases when you will be able to know that the other side is not responding or something wrong is happening (e.g., somebody is disconnecting link from the router).

This optimization is to specifically address the case in our hyperbolic tests when NFD is killed to simulate a link failure. Each neighbor will receive a face destroy event and so can more quickly recalculate its routing table.

Alex: just want to clarify -- we still have the Hello messages to detect the link/neighbor failures, so even if there's no face failure event notifications, these failures will still be detected. This patch is to handle the case when there's a face failure event notification. Previously the routing table was not immediately recalculated, which causes packet drops unnecessarily.

Let me say this way. I'm in no way against the change, as it will speed up routing table calculation. I just want you to be cautious using this feature in any comparison evaluations. It can be done, but with statement that this is evaluation of real link failure when routers can easily detect such event.

Alex: I see your point now. There are two separate questions: (1) in real networks, are there such notifications of link failures? (2) does this optimization affect/bias any of our evaluation studies? For (1), IP networks have BFD (Bidirectional Forwarding Detection) to detect link failures. This feature is widely supported by existing hardware (http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fs_bfd.html). NDN should have something similar, as discussed before. For (2), this optimization won't bias our comparison of hyperbolic routing and link-state routing since they share the same code logic for the most part. In the case of hyperbolic routing, it should also react to such local failure notification by immediately adjusting its RIB entries. For example, let's assume Face A and B are the best two faces to a name prefix P before the failure. If Face A fails, Hyperbolic Routing should recalculate the best two faces, say Face B and C, and update the RIB/FIB. Vince needs to double check that this is what happens in the code.

Lan Wang wrote:

Alex: I see your point now. There are two separate questions: (1) in real networks, are there such notifications of link failures? (2) does this optimization affect/bias any of our evaluation studies? For (1), IP networks have BFD (Bidirectional Forwarding Detection) to detect link failures. This feature is widely supported by existing hardware (http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fs_bfd.html). NDN should have something similar, as discussed before. For (2), this optimization won't bias our comparison of hyperbolic routing and link-state routing since they share the same code logic for the most part. In the case of hyperbolic routing, it should also react to such local failure notification by immediately adjusting its RIB entries. For example, let's assume Face A and B are the best two faces to a name prefix P before the failure. If Face A fails, Hyperbolic Routing should recalculate the best two faces, say Face B and C, and update the RIB/FIB. Vince needs to double check that this is what happens in the code.

Yes, the code will also affect hyperbolic routing. An adjacency LSA build and routing table recalculation will be triggered by a face destroy event for both routing protocols.