[Feature Request]: Option to limit traffic based on original hop settings

[PaulOckenden]

Platform

other

Description

Background: Here in the UK we have restricted airtime. And now in some parts of the country the mesh has become severely congested - almost to the point where it becomes unusable. This seems to have coincided with many users setting their max-hops to seven, rather than the recommended three.

Possible solution: An option in the Lora config, alongside the ability to set the hop count, which basically says "don't repeat anything with an original hop count higher than our local setting" - in other words just drop all these 7 hop packets.

The effect of this change would be twofold: Firstly it would start to reduce the congestion on the mesh. But secondly it would discourage people (especially those in areas with restricted airtime) from setting their hop count higher than the value that's strongly recommended in the Meshtastic docs!

It would obviously need a firmware update and then additional work from those responsible for the clients, in order that this option could be enabled. Just needs a binary on/off via whatever UI device the client normally uses.

[BrianDrury]

Sounds like a very good idea to me.

[Jorropo]

A solution with less knobs could be to compute the next hop as min(msg.current_hop -1, node.hop_limit) so if you have MAX_HOP set to 3 and you receive a message with 6, you would relay with 3.

[PaulOckenden]

A solution with less knobs could be to compute the next hop as min(msg.current_hop -1, node.hop_limit) so if you have MAX_HOP set to 3 and you receive a message with 6, you would relay with 3.

Possibly. But if big-hop packets were simply dropped and not forwarded by nodes using the option I suggested it might encourage people not to use mesh-unfriendly settings in the first place. Although I do understand that in a few very special circumstances using a large hop count might be beneficial. So in those areas people could simply leave the option unticked.

[Jorropo]

I see two issues with dropping them:

• it's hard to debug, you raise your hop limit and things starts not working because your neighbors configured it, you don't get any error message and it still kinda work, as zero-hop messages, so it's flaky and extremely hard to debug.
• it actually promote worst routing topologies, because you don't relay the message other nodes in the mesh that are closer and in worst position to relay the message might relay the message instead. Relaying with a lower number will make anyone else who heard the original 7 hop and your 3 hop relay, cancel their own relay attempt.

[noon92]

This is similar to #3833

[PaulOckenden]

This is similar to #3833

Indeed. Although of course a repeater with ‘don’t decrypt’ enabled (as most routers seem to be) won’t do this. But I was thinking more of general nodes in the mesh, as opposed to routers and repeaters.

[GUVWAF]

@Jorropo Has two valid points as to why this would not be desirable.

With the next-hop router (#2856), excess rebroadcasts due to high hop limits will be avoided for DMs already. Furthermore, already now the hop limit for ACKs and responses will be dynamically adapted based on the amount of hops that was required.

I'm converting this into a discussion. Don't think it's needed to implement this in the firmware. In my opinion you should either educate the people using your public mesh, or move to a private one. The hop limit is only one configuration setting that users can set wrongly/too aggressive. Enabling MQTT downlink or setting high update intervals for telemetry, position, etc. are also very important factors that contribute to the channel utilization.