Proposal: Flood retransmits of retried direct messages should use a limited TTL derived from original PATH

[rvleij]

Following up on the discussion in #1342 I have a simple approach that would win something short term and prepare for regional (or other smart) flooding in these cases.

The case is that a DM is not ACKed (which for me happens most of the time somehow), and the DM is then flooded.

Instead of adding complexity to repeaters or clients (graceful deg of path, repeater swarming, etc), I'd just make sure that the retransmission (flood) when a direct path fails to receive an ACK gets broadcasted with a lower TTL (I propose 1.2 x rounded up. So if my original path was 4 hops, I'd set TTL to 4.8 (meaning 5). We can make exceptions for low number of hops (like under 3 hops we just add 3 or something similar). This way the retransmit flood is limited to the region (network hop wise) instead of the full network.

That would help with the congestion in busy meshes until we have a better way of dealing with this (I'm in NL).

The hooks and changes would be prep work to implement smarter fallbacks in case DM fails.

I could (try to) write up something, but I first want to understand what the community thinks.

BTW: Is there a vision on technical direction as in:
A) Create client (or repeater) side intelligent ways to optimize network
or
B) Keep is simple (like I would definitely count the above proposal under)?