[Suggestion] [repeaters] add option to repeat in specific time windows, and to drop packets if enough repeats were heard.

[dreirund]

While MeshCore in some regions already really gets problems due to airtime collision (the vast majority of packets in MeshCore are flood packets), Meshtastic has already taken one evolution step from this and created different time windows ("Contention Windows") that do not overlap in which different node roles might repeat a message.

I hereby suggest for MeshCore repeaters a mechanism that deterministally allows

• that repeating is happening only after a configurable delay, and after that has passed with the configurable randomness,
• that it can be configured that packets are not repeated if n repeats have already been heard.

Regards!

[CullenShane]

Everything you mention is currently in place, with the exception of the packet getting dropped for some number of repeats.

See this guide for how those settings apply: https://denvermc.com/guides/repeater-setup

Personally, I am not in to the idea that flood packets get dropped randomly if too many repeats are heard. Flood packets are how direct packets happen, if a key repeater opts to ignore a packet that is the difference between my direct message path being found and not. For instance what if the repeater that chooses to drop the message is a key connector repeater that connects two disconnected parts of the mesh?

This proposal quickly balloons in complexity in code and in administration when a simple solution is to put up less repeaters.

[dreirund]

Everything you mention is currently in place

well, not really:

See this guide for how those settings apply: https://denvermc.com/guides/repeater-setup

Thanks for that link! Although it is still unknown how txdelay and rxdelay act precisely, they seem to give some empirical hints.

txdelay and rxdelay are statistical values, they cannot do anything deterministic, as far as I understand by now.

Personally, I am not in to the idea that flood packets get dropped randomly if too many repeats are heard. Flood packets are how direct packets happen, if a key repeater opts to ignore a packet that is the difference between my direct message path being found and not.

Should be a config option and off by default, and configurable to <n> where <n> is the number of heard repeats.

But yes, I also think it is difficult to set this correctly if someone wants to, maybe causing more confusion than use.

In practice, currently there are already high collisions in dense meshes, it could be a hit or miss (making overall statistics better or worse).

[CullenShane]

Yea, there's an incredibly densely deployed neighborhood near me and getting packets through there is challenging at best, it's usually best to go around.

It feels like both problems (the current problem and the proposed solution) are actually still the same fundamental education problem where the repeater deployer has to know what they're doing to be net good to the mesh. The real question is which is the least bad option for the health of the mesh when an new user is deploying a repeater?

Or is there something the app can do to educate the user that possibly they don't need a repeater?

Ultimately these are communication devices, and education through public channel is a factor here as well

[dreirund]

where the repeater deployer has to know what they're doing to be net good to the mesh

There is the additional case where someone (I) need a repeater close by so that I have access to the mesh in my flat in the basement, but coverage above the roofs is really good and the repeater is not doing anything good to the rest of the mesh, but needed so that persons down in the local house(s) have mesh access.

I was mainly thinking of that case.

Other ideas how to improve for them? Intentionally low transmit power?

[CullenShane]

need a repeater close by so that I have access to the mesh in my flat in the basement, but coverage above the roofs is really good

Yea, I think lowering power for that repeater and doing very very fast repeats will be the least bad for the rest of the mesh.