rns.recipes

gdane wrote:

First, it won't detect an asymmetry with the destination node (where C can't hear B in your example) because that node will never repeat. Active neighbor probing would detect this (assuming the destination node has probes enabled) and could potentially stop responding to path requests for C (a slow convergence).
Second, it won't work at all on non-broadcast transports of course, but I think that's ok considering those don't typically suffer from asymmetry anyway.

You are absolutely right in both points. We definitely have to consider these edge cases! Thanks for bringing that up.

Regarding your first edge case: next hop is final destination
The good thing is, we know that the next hop is the final destination. We therefore know that there won’t be a repeat of the packet. In these cases we can only use PROOF/LRPROOF packets to set the neighbor as RESPONSIVE/UNRESPONSIVE (simple PROOF can only be used to set a neighbor RESPONSIVE, LRPROOF can also be used to set a neighbor UNRESPONSIVE, since it is mandatory).
As far as I understood, the probe destination can only be enabled if the device is in transport mode, right? So as of right now, probing would also be no option in this case. But I guess that could be easily changed.

Regarding your second edge case: non broadcast transport medium
This is more tricky and also applies to a change of the transport medium. Imagine a device receives a packet over LoRa and forwards it to the next hop over TCP. This would break the passive responsiveness detection.

Maybe combining these approaches is an option: Passive listening for most of the cases and active probing for the edge cases. (As far as I know, PROOF/LRPROOF are already used as first indicator for responsiveness)
Btw: Having the probe destinations enabled by default – also for non-transport nodes – might support such a system.

gdane wrote:

Not sure I follow this exactly so could use some clarification. The neighbor responsiveness is already tracked in a separate table in microReticulum,_neighbor_stats.
It's true however that when a neighbor is deemed to be unresponsive, it does trigger a potentially expensive walk of the full path table.
Are you proposing to track neighbor responsiveness along with destination in a separate table, or something else?

Oh, I have to admit I did not check the code. I understood your comment, that you used the existing mark_path_unresponsive() function:

Currently it just triggers the same unresponsive path handling as the Python reference implementation through Transport.mark_path_unresponsive(), and I believe you're correct that the next announce from that node will
reset it. I think we can do better than this though, and at least compare the received announce neighbor against the neighbor that is unresponsive and reject it for some period of time.

What I meant is, that path_state and _neighbor_stats serve different purposes and should not be combined. Example: If Node A identified the neighbor transport node B as UNRESPONSIVE, ALL paths with Node B as next_hop could be allowed to be overwritten by a fresh announce from a responsive neighbor – even if the hop count is higher. The goal should be to prefer responsive neighbors somehow.
Furthermore, there might be many other paths that would also need to be set to UNRESPONSIVE (I guess this is the expensive walk of the full path table?).
It would be much easier to just check the neighbor_state if necessary, because this is one entry that has an impact on many paths at once.

nilu96 wrote:

Regarding your first edge case: next hop is final destination
The good thing is, we know that the next hop is the final destination. We therefore know that there won’t be a repeat of the packet. In these cases we can only use PROOF/LRPROOF packets to set the neighbor as RESPONSIVE/UNRESPONSIVE (simple PROOF can only be used to set a neighbor RESPONSIVE, LRPROOF can also be used to set a neighbor UNRESPONSIVE, since it is mandatory).
As far as I understood, the probe destination can only be enabled if the device is in transport mode, right? So as of right now, probing would also be no option in this case. But I guess that could be easily changed.

You're right, probe support is only enabled in transport mode. As you said though, this could be changed. It could even be added by apps outside of the reference implementation if necessary for apps that want to participate in active neighbor probing.

Regarding your second edge case: non broadcast transport medium
This is more tricky and also applies to a change of the transport medium. Imagine a device receives a packet over LoRa and forwards it to the next hop over TCP. This would break the passive responsiveness detection.

Maybe combining these approaches is an option: Passive listening for most of the cases and active probing for the edge cases. (As far as I know, PROOF/LRPROOF are already used as first indicator for responsiveness)
Btw: Having the probe destinations enabled by default – also for non-transport nodes – might support such a system.

I agree. Passive wherever possible with fallback to active when required and supported.

What I meant is, that path_state and _neighbor_stats serve different purposes and should not be combined. Example: If Node A identified the neighbor transport node B as UNRESPONSIVE, ALL paths with Node B as next_hop could be allowed to be overwritten by a fresh announce from a responsive neighbor – even if the hop count is higher. The goal should be to prefer responsive neighbors somehow.
Furthermore, there might be many other paths that would also need to be set to UNRESPONSIVE (I guess this is the expensive walk of the full path table?).
It would be much easier to just check the neighbor_state if necessary, because this is one entry that has an impact on many paths at once.

That's right, the "expensive" part on an embedded device is walking a path table of potentially thousands of paths strewn across flash storage.
Sounds like what you're describing is using a combination of neighbor_state and path_table to determine if a path is RESPONSIVE.
This would be much more efficient since the set of active neighbors (those involved in actual traffic exchange) will be much smaller than the full path table, and the subset of unresponsive neighbors will be much smaller even than active neighbors, it would be efficient to determine unresponsive state on a need-to-know basis for a path by checking the state of its next-hop (or final dest if no next-hop) in neighbor_state instead of reading/writing that state from/to the path table.

I still prefer the idea of acknowledgement messages more generally but passive listening does make sense for LoRa due to the constrained bandwidth, I think both should be used (Maybe if the user is connected to a slow LoRa channel they can simply not ask for a acknowledgement packet and only use that method, depends on the exact implementation of either).

Apologies if I'm just repeating myself I like acknowledgement because it gives the client and every transport node just enough information to have good routing. Announcement packets are fine but they are only good for finding that a destination exists and that there is a possible path had existed at some point, they can't tell you how much bandwidth or latency there is or if the connection is stable. But with acknowledgements any node on the way to the destination including the client can implicitly figure out packet loss and latency for each interface in real time based on the ratio of sent packets and how many acknowledgements have been sent back, and adjust where everything is getting sent based on that.