Exploring Routing Optimization via Hop Count

[Pablitosalinero]

Platform

Cross-Platform

Description

Background

I have been looking into the current next-hop routing mechanism and I would like to share a suggestion for a potential improvement. Please note that I am relatively new to this codebase, so I welcome any feedback on whether this approach aligns with the project's architecture.

Problem Observation

Currently, next-hop routing seems to rely on the "last successful relay" heuristic. While functional, this can sometimes lead to sub-optimal paths being selected (e.g., a longer path replacing a shorter one just because it was heard more recently). Additionally, there might be scenarios where a route becomes "stale" (relay moving or powering off) and the node remains assigned to it until a transmission fails.

Suggestion: Lowest Observed Cost with Route TTL

The idea would be to move towards a "Lowest Observed Cost" model using the metadata already available in the packets.

1. Hop Count as a Routing Signal

We could use hop_start - hop_limit to calculate the hops_away. This metadata is already present and could provide a simple way to prioritize shorter paths.

2. Potential Decision Logic

When a packet is overheard from node D via relay R:

• Shorter Path: If the new path has fewer hops, update the next_hop.
• Equal Path: If it's the same distance, refresh the assignment to keep it current.
• Longer Path: Only consider switching to a longer path if the current one has not been "confirmed" for a certain period (e.g., 30 minutes), suggesting the optimal route might be broken.

3. Route Freshness Tracking

To avoid interfering with the last_heard field (which is important for UI/Online status), we might consider adding a dedicated field to the node database, such as:

• next_hop_last_confirmed: A timestamp to track specifically when the route was last verified.
  This would allow the routing table to age independently of the node's general activity.

Conclusion

This is just a preliminary suggestion to see if you find it worthwhile to explore. The main goal is to increase mesh efficiency with zero protocol overhead. Let me know what you think!