[Feature Request] Fuzzy/thick directed paths

[redxdev]

Right now if you send a direct message if you previously have known a path then you depend on every repeater in that path being available. This is not super reliable, especially when sending with a spotty connection, and means that you end up having to fall back to a flood message. On larger meshes it is best to reduce flood traffic wherever possible, so I'm proposing a step in between direct and flood routing, using "fuzzy" or "thick" paths instead of direct paths.

The problem with anything that is in between direct and flood is, of course, the lack of routing information in the mesh. But repeaters already collect one extra bit of routing info that isn't currently used: direct (0-hop) neighbors. Thus, my proposal is that a "fuzzy" path would not just have repeaters directly in the path repeat the packet, but also any 0-hop neighbors of those repeaters.

To illustrate, let's say we have repeaters A, B, and C - all neighbors of each other, and my destination companion of D. I send a message with a path of A,B,D but B fails to respond. On my second try, I send using a "fuzzy" path of A,B,D - B still fails to respond but C, knowing that it is itself a neighbor of B, repeats (making the resulting path A,C,D).

The repeater's logic would effectively be this:

• If fuzzy path
  • If I'm part of the path - > repeat
  • If I'm not part of the path, but a known neighbor is -> repeat
  • Otherwise -> don't repeat

The effect is sort of localized/directed flood routing that doesn't require any new routing information or communication beyond what repeaters already collect, and in theory it raises the chances that contact with the destination is made if the direct path previously failed.

The immediate problems that come to mind that would need solving:

• Figuring out how to flag a packet as requesting a fuzzy path, without breaking backwards compatibility.
  • Ideally old firmware would be able to treat fuzzy paths the same as direct paths, but this might simply not be possible with the current protocol.
• When should fuzzy paths be used?
  • The first thing that comes to mind is to use it as part of retry logic when a DM isn't ack'd, after attempting a direct path and before a flood. But maybe there are other times it'd be useful to use.
• How should a packet's path be modified when a different repeater than intended repeats the message?
  • I would assume it should replace the neighbor it repeated for, but this begs the question of how to handle a path where the repeater is neighbors with multiple others in the path - which does it replace? All neighbors? The first? The last? I don't think there's info about how far a packet has traveled on a path so it becomes difficult to figure out where in the path a repeater has been changed.
• Should a fuzzy path result in a companion updating the path it has to another companion?
• What kind of settings should repeaters have for fuzzy paths?
  • We would probably want controls over the max age of neighbors to consider (don't repeat messages for neighbors if you haven't heard from them in over x days - there's a point at which new paths should be established) and minimum RSSI (don't repeat messages for neighbors if you haven't heard them strongly enough, as that might mean you're pretty far away from the path).

I'm not super knowledgeable about designing mesh networks and maybe there's something problematic I've overlooked with this idea, but I wanted to start a discussion on whether this is something reasonable to look further into.

[redxdev]

One "easy" (but maybe not good) option for flagging a fuzzy path would be to use FF or 00 as the first or last member of a path. Though I'm not sure if those were reserved for some other purpose.