[Feature Request]: Have client nodes ignore rebroadcasts by router/repeaters in their decision to rebroadcast or not

[NomDeTom]

Currently even well-placed router nodes represent a risk to local mesh working, because they pre-empt all other retransmissions to yeet the packet as far as possible, and don't take account of potentially hidden or over-shadowed nodes that rely on a client rebroadcast to receive their packets.

Interim solutions such as client_base solve this on a pre-planned basis, and router_late reduces the impact of overshadowing on the first rebroadcast. However, the role of a router is to give a guaranteed broadcast the packet further than a normal client can reach. If client nodes hear a router rebroadcast, they shouldn't take it into account in their own managed-flood calculation.

Essentially, this reduces the influence (and perhaps some benefit, since we're eating into clear ChUtil for the router) of router nodes, and encourages local meshing activity.

[ndoo]

Hm, the problem described would affect anyone who has a rooftop/balcony CLIENT then an indoor CLIENT right?

Looks like I should switch hilltop ROUTERs in my area to ROUTER_LATE then, since the scenario I described above is very common here.

[Ryu945]

This could solve some problems at the expense of bandwidth. I wonder if this idea would solve the problem while not using as much bandwidth though.

Instead of ignoring routers, nodes keep a database of who around them can directly hear who around them. In this scenario, node B would keep a record of node A, Router and node C. Node A would only keep a record of node B since no one else is around them. Node C would only keep node B since no one else is around them. Router would only have a record of node B since no one else is around them.

Then devices compare this record to their neighbors only. In this comparison, node B would realize that C cannot see Router or node A. Node B would also realize that Router can't see node A or node C. A Client node would only silence their rebroadcast if the person that rebroadcasted first doesn't have any blind spots. B would always communicate and never get silenced by Router because it has two nodes that it can reach but router can't.

A newly turned on node that doesn't have data would just not rebroadcast if another node rebroadcast first since a node will only rebroadcast after another node has already rebroadcasted if it knows for a fact that it has a node that the first rebroadcaster can't reach.

The bandwidth impact on the network could further be reduced if better broadcasters are given a rebroadcast advantage. For example, a timing offset based on the Meshtastic device used or a new mode that users can setup that grants a timing advantage for well placed nodes.

[korbinianbauer]

node B would realize that C cannot see Router or node A

How?

[Ryu945]

node B would realize that C cannot see Router or node A

How?

One possible implementation is for nodes to broadcast who their neighbors are similar to how telemetry is done now.

[korbinianbauer]

One possible implementation is for nodes to broadcast who their neighbors are similar to how telemetry is done now.

That would either always be outdated and fail a lot, or require a LOT of traffic.

No, not aborting retransmissions due to ROUTER and ROUTER_LATE is the right way to go, and since the introduction of the relay_node header field, it should be straightforward to do.

[GUVWAF]

I’m not so sure about this one, it really depends on how roles are used. Indeed this idea would solve the issue in the depicted scenario, but you can get very similar results by using a combination of ROUTER and ROUTER_LATE/CLIENT_BASE.

However, being able to quickly “shut off” nodes is unique to ROUTER and is very useful in certain cases (I think @b8b8 agrees). It can eliminate rebroadcasts of CLIENTs that contribute very little and would be covered by the ROUTER anyway.

A different (and easier) way to limit a ROUTER’s capability to shut off nodes might be to get rid of its prioritized window. I don’t really see a need for that anyway if the idea from this issue would be implemented.

However, this is all about the trade-off between unnecessary rebroadcasts and refraining from rebroadcasts too much. “Managed flooding” is a spectrum and I believe we should be careful with shifting more towards “pure flooding”. For example, if this would be implemented, I’m not sure #7994 should be done also, and vice versa.

[korbinianbauer]

However, being able to quickly “shut off” nodes is unique to ROUTER and is very useful in certain cases (I think @b8b8 agrees). It can eliminate rebroadcasts of CLIENTs that contribute very little and would be covered by the ROUTER anyway.

I feel like as long as there's no additional cost for sending 7-hop broadcast packets vs. being nice about available airtime, it's kind of nonsensical micromanaging to try to reduce congestion by shutting down rebroadcasts of packets that are already on the go, unpredictably from far away.

However, this is all about the trade-off between unnecessary rebroadcasts and refraining from rebroadcasts too much. “Managed flooding” is a spectrum and I believe we should be careful with shifting more towards “pure flooding”.

Definitely. It would be much less painful to manage the congestion issue before even sending though, rather than having to decide when to not rebroadcast a packet that's already out and expected to arrive according to the hop_start.

I know there's some throttling already scattered over the firmware code, but it doesn't really consider channel utilization until it's too late

[github-actions[bot]]

This issue has not had any comment or update in the last month. If it is still relevant, please post update comments. If no comments are made, this issue will be closed automagically in 7 days.

[NomDeTom]

I think Burr said something along these lines, with ignoring very low signal strength repeats.