Add next-hop retry for direct-path relays

[benallfree]

This is a draft for visibility.

I have an idea to make set paths work more reliably by making each hop listen for a small zero-hop hard ack and retry if it doesn't hear one.

Right now, repeaters relay-and-forget. Any missed link in the path results in a timeout and the user has to retry the entire path.

Prior art:

• For packets with a path set; auto try again if no echo was heard. High Availability Link for Overwhelmed Meshes - Project HALO. Stop the flood #2367
• Keymind - Keep Ensuring Your Message Is Network Delivered #2501
• Feature: Repeated sending for DIRECT-route packets with echo-cancellation (improves delivery, reduces floods) #2670

From what I can tell, these listen for the message echo. That was my first instinct too, but after more thinking I feel this may actually make the problem worse on the links that need it most. It is good because it costs zero extra airtime, but it is risky on weak/problematic/busy links because the airtime needed to hear the echo dramatically increases the chance of collisions and errors. In contrast, a hard ack is about 12 bytes regardless of the original message size. So for 12 extra bytes of airtime, you get the most reliable ack's possible.

[usrflo]

Hi @benallfree ,

> From what I can tell, these listen for the message echo.

that's right, at least #2670 and #2367 do.

> That was my first instinct too, but after more thinking I feel this may actually make the problem worse on the links that need it most. It is good because it costs zero extra airtime, but it is risky on weak/problematic/busy links because the airtime needed to hear the echo dramatically increases the chance of collisions and errors.

The approach of PR2670 is to listen as long as possible and keep deafness low (prevent TX, prevent calibration that blocks RX) on the sending node. If a node is stressed with TX it may not hear a downstream package repetition so it will resend its package which is unnecessary. So yes, in busy environments the error correction remains but the package frequency becomes higher. I tried to reduce the probability of collisions by checking for noise before repeating a package but yes, the more traffic the worse the quality gets. But still better for deliverability than with common MeshCore without the duplication.

> In contrast, a hard ack is about 12 bytes regardless of the original message size. So for 12 extra bytes of airtime, you get the most reliable ack's possible.

That means to at least double the amount of TX for a direct message plus possible repetitions if the ACK was not received by the sender. Plus special collision problems when the ACK packages cannot be heard and the sender repeats its package.
In contrast to that I think "less is more": within PR2670 the regular package sent by a downstream repeater is considered as the ACK you're focusing on; in my view a duplicate confirmation does not change the situation but increases TX. Do I miss something?

Side note: package resending like with PR2670 is downwards compatible; so it works without updating all other nodes.
According to your explanation IMHO a repeater with your draft reacts on "no ACK received?" with a re-sending: this would multiply all direct packages as long as the surrounding repeaters are not updated, isn't it?