[Feature Request / Question]: Is it possible to use hoplimit only for broadcast messages?

[ygguser]

Platform

ESP32

Description

As far as I understand, the limit on the number of hops is used in order to prevent excessive exposure to the radio channel. But, as it seems to me, the increased load will only be when sending broadcast messages. When sending targeted messages, the channel should not be heavily loaded.
Is it possible to use hoplimit only for broadcast messages?
In this case, it would be possible to send addressable messages over much longer distances...

[QuadrifoglioVerde]

Likewise, the hop limit could be configurable for telemetry and other non‑text messages, and separately for text, so that the network wouldn’t be congested by telemetry from nodes with a hop limit set to 7.

[korbinianbauer]

The load on the mesh that next-hop routed ("targeted") packets cause does indeed scale more gracefully than it does with flooded packets, e.g. broadcasts.

How much exactly depends on the mesh topology, but a crude average over many simulations looks like this. The unit here is "number of nodes that have to transmit the packet".

However, next-hop routing is not guaranteed to work, and when it doesn't it will fall back to flooding to deliver the message and to try and find a new working route. So here you'd have to make a decision:

If next-hop routing a DM doesn't succeed, what do we do? Give up and be stuck unable to send another DM to that recipient ever again? Or launch a broadcast without any hop limit to find a new route?

Likewise, the hop limit could be configurable for telemetry and other non‑text messages, and separately for text, so that the network wouldn’t be congested by telemetry from nodes with a hop limit set to 7.

You'll find there's plenty of users that use Meshtastic for telemetry first and really don't want to give up the ability to send telemetry over 7 hops.

If there were individual settings, I'm pretty sure most everyone who has set their hop limit to 7 now, would then just set both hop limits to 7.

[ygguser]

However, next-hop routing is not guaranteed to work, and when it doesn't it will fall back to flooding to deliver the message and to try and find a new working route. So here you'd have to make a decision:

If next-hop routing a DM doesn't succeed, what do we do?

It seems to me that in the case of addressable, non-broadcast message sending, you can opt out of the flooding approach, and if the message could not be delivered using the neighbor table, then, well, so be it, the delivery failed... Maybe in this case it would be appropriate to give the user a message like "Try sending the message again later."

[korbinianbauer]

@ygguser

That's a possible approach from the technical side, but I don't think the user experience would be reasonable for practical messaging. The route has to be established first, so messaging usually has to start with a flooded message. It's not impossible that there's an established route as a result from other, earlier transmissions over parts of the route that add up to a working longer route, but that would be pure luck.

Out of curiosity, it certainly would be interesting to see how far you can push it: What's highest number of hops you can occasionally get a packet to travel across? But the current protocol wouldn't tell you how many hops the packet has travelled, so even that use case isn't really there.

What's currently limiting the distance over which you can have conversations really isn't the hop limit, it's the reliability of each individual hop.

[dem1tris]

@ygguser Is your suggestion aimed to solve the particular problem within your mesh? Could you please share the problem you faced?