Feature: redundancy-aware flood suppression for traffic reduction (simple_repeater)

[usrflo]

Cancels a repeater's own scheduled flood re-broadcast when neighbouring repeaters in areas with dense coverage have already forwarded the same flood - i.e. when the re-broadcast would be redundant. Cuts on-air flood traffic and collisions while preserving reach.

How it works

Each overheard neighbour forward of a flood is counted at RX-arrival time (logRx), weighted by link SNR (strong → +2, weak → 0); once the weighted count reaches the self-tuned threshold, the already-scheduled re-broadcast is cancelled.

See README-flood-suppression.md for a detailed explanation of the mechanism and configuration.
The feature is on by default; set flood.suppress off disables it.

Intended role

This feature is for subordinate repeaters - nodes whose coverage is largely redundant with their neighbours.

• Backbone / region-linking repeaters with wide coverage should leave it OFF. Their re-broadcast carries reach between regions; suppressing it can isolate the far side. For a node with a known bridge role, disabling it explicitly is the safe choice.
• Dense, subordinate repeaters should enable it - that is where the packet-count and collision reduction pays off.

Adaptive mode encodes this automatically (sparse neighbour table → no suppression; dense core → aggressive), so a well-placed fleet usually needs no per-node tuning - but operators should still keep bridge nodes off the feature.

Validation

Simulation A/B results (mcsim):

	Flood TX	Flood airtime	Collisions	Coverage
off → on	237 → 163 (−31 %)	−31 %	142 → 57 (−60 %)	0.308 → 0.308 (preserved)

[usrflo]

This PR ist part of the ufo firmware, latest build at time of writing: v0.6

[ViezeVingertjes]

Just a heads-up; similar idea's / PR's have been there in the past, but it doesnt hold up with real-world scenario's as repeaters don't know about neighbors their locations, links arent symmetric or might be there one second, not the other, packet loss, invisible neighbors, neighbors that been replaced etc.

Few examples that were brought up in the others:

• Repeater A could here 100 repeats; but the one it did not hear or know about might be the one connecting a whole different country.
• Signal strength isnt reliable, A<>B could be 1 meter appart, yet not share the same neighbors / connect the same clusters.
• Preset / TCP Bridges, multiple nodes on the same antenna mast (Yagi's, omni etc), a lot of weird scenario's that will causse problems.

[usrflo]

@ViezeVingertjes, thanks for your feedback. These are true concerns to raise for any broadcast-suppression scheme. Let me be precise about what this does and doesn't do: some of the failure modes you describe are ones it's specifically built around and the most important point is who it's for.

Scope first, because it answers your strongest example directly. This is a knob for repeaters that sit inside a dense local mesh - the ones hearing the same flood re-broadcast by many neighbours, where their own rebroadcast is pure redundant airtime and collisions. It is not for the large inter-regional distribution repeaters that bridge clusters or carry traffic across regions. Those nodes should forward every flood packet and should run with this feature off. So "the one repeater A didn't hear connects a whole different country" - that country-connector node is, by definition, not the target audience, and it should leave it disabled.

What it is not: it doesn't touch routing, doesn't use location and doesn't decide who to send to. It only ever cancels this repeater's own already-scheduled rebroadcast, and only when it has overheard multiple strong neighbours already forward the identical flood before its own TX fires.

On the specific points:

• Asymmetric links & invisible neighbours (the real residual risk). Fair - and it's exactly why the scope above matters. SNR is the received SNR; A doesn't know whether B can hear A back. If a node is simultaneously embedded in a dense strong-SNR cluster and is the sole bridge to a fringe region, the heuristic of this feature could over-suppress, because SNR measures "central," not "bridge." The answer here is operational, not algorithmic: if a repeater is a distribution/backbone node, keep it off. Within a genuinely dense mesh the residual risk is far smaller, and the threshold self-disables on sparse nodes (too few known neighbours → no suppression at all).
• Packet loss. Suppression requires successfully overheard forwards, so loss biases toward not suppressing: if forwards are lost to noise or collisions, A hears fewer, the threshold isn't met, A rebroadcasts. The failure mode under bad RF is the safe direction - more reach, not less.
• It can't collapse to "everyone cancels, nobody forwards." A can only overhear a forward if a neighbour actually transmitted it. The first relay to fire (edge nodes get a shorter TX-delay deliberately) emits; the later, more-central relays then cancel. Worst case is "fewer forwards than ideal," never "zero forwards."
• Multiple nodes on one mast. That's actually where suppression helps most and is least risky: co-located nodes hear identical forwards and drop their redundant copies, but the mast still emits once (whoever fires first), covering exactly what that mast covers. The N−1 redundant emissions from the same antenna were pure waste.

It's a per-deployment master switch (flood.suppress off), default-on but trivially disabled. The intended deployment pattern is exactly the split your examples point to: enable it on the dense-mesh repeaters, leave it off on the inter-regional backbone.
Did I miss something?

[usrflo]

Usage:

• get flood.suppress / set flood.suppress <state>
• get flood.suppress.snr.hi / set flood.suppress.snr.hi <dB>
• get flood.suppress.snr.lo / set flood.suppress.snr.lo <dB>
• get flood.suppress.delay.factor / set flood.suppress.delay.factor <n>

Parameters:

• state (flood.suppress): on|off - master switch (disables the feature entirely when off)
• dB (flood.suppress.snr.hi): -30..30 - overheard forward with SNR >= this counts double (central/redundant relay)
• dB (flood.suppress.snr.lo): -30..30 - overheard forward with SNR < this counts 0 (preserve edge reach)
• n (flood.suppress.delay.factor): 0..8 - extra TX-delay multiplier for central flood relays (widens the cancel window so a redundant rebroadcast is more likely to be observed and cancelled)

Defaults: flood.suppress = on · flood.suppress.snr.hi = 9 · flood.suppress.snr.lo = 0 · flood.suppress.delay.factor = 2

---

With the latest checkin statistics on flood suppression can be viewed, sample:

> get flood.suppress
> on, suppressed 5140/9800 (52%)

[ViezeVingertjes]

Did I miss something?

This is one of the examples where you shouldnt rely on Claude, because it's simply does not understand real-world effects of RF and meshing honestly.

Things it comes up with; let's pick just one example:

Multiple nodes on one mast. That's actually where suppression helps most

Are simply false, if those would supress on the same mast, it would be a disaster, they are yagi's covering different area's, one not sending means a whole cluster being deaf, but it doesnt understand that and it would become a dice roll which cluster gets what message.

Same with topology and the RF quirks, which is why it keeps suggesting this suppression over and over.

[usrflo]

@ViezeVingertjes , I agree: "on the same mast" rarely means multiple omni-directional antennas but rather directed ones. And in the latter use-case an overheard package should not apply to the flood suppression.

I think it would be good to introduce "repeater roles" in MeshCore:

• in the initial setup this would preset settings according to the role
• and sending out the role information within adverts or within neighbor responses would mean other repeaters can react upon the role information

Repeater Role examples:

• BACKBONE: inter-regional, directed, gateway; preset: flood.suppress off, flood.max higher value, loop.detect strict
• EDGE: border repeater; preset: flood.suppress.off, loop.detect minimal
• LOCAL: dense city mesh; preset: flood.suppress on, tx lower value, flood.max lower value, loop.detect moderate

The flood suppression feature could limit its suppressions if >= C same packages were heard by LOCAL repeaters.
A directed antenna would be excluded by the BACKBONE role.

[usrflo]

@ViezeVingertjes : regarding the topology aspect and the admin efforts to differ between pro's and con's to enable and disable the flood suppression I was thinking about another approach to take the coverage of clients (companions, sensors, room servers) and nearby repeaters into account.

Whenever a client is auto-registered to be in use of a repeater the repeater forwards flood packages with relevance to them. There is no client-relevance for repeater focused packages like TRACE and CONTROL. There is no relevance for floods that try to contact an unregistered client. ADVERTs or GRP_* are relevant always, so no suppression occurs.
BTW: it's interesting to see what clients are in direct use (zero-hop) of a repeater, so the cli command 'clients' is a counterpart of repeater 'neighbors' in my experimental implementation:

>  clients
1C1944EF:0s
1D:2794s
6D:1028s
>  neighbors
09D7B955:15:0
EB98B62A:17:-17
C130EE47:19:11
9D04BA61:88:-17
A62EEA6F:97:48

The flood suppression only refers to strong, well-connected neighbors. You pointed out that coverage is a critical criteria and I agree: the true connectivity beyond the nearby repeater decides about blocking a flood re-sending.
Well connected neighbors are limited to the top x (x=5 currently) in my implementation to prevent too much coverage coordination traffic and focus the suppression on truly redundant neighbors. If a new repeater is added to the top-x nearby repeater list a soft TRACE to check bi-directional links beyond the other nearby repeaters is started (trace rep_new,rep_other + trace rep_other,rep_new). Soft means: low TX power and very rare (currently results are kept for 36 hours) to keep collisions low. The result is a coverage graph of nearby repeaters so the edges can be checked.

>  near
near snr_lo=0 cap=5 n=3
meas sent=43 ret=15 edge=6 tmo=5
A62EEA6F:101:48
C130EE47:23:11
09D7B955:19:0
>  reach A62EEA6F
<C130EE47,09D7B955
>C130EE47,09D7B955
>  reach C130EE47
<A62EEA6F
>A62EEA6F
>  reach 09D7B955
<A62EEA6F
>A62EEA6F

Finally the coverage information is used to decide about a re-sending of a nearby FLOOD: when a near neighbor is heard to send out the package it is checked if a) there is client relevance, otherwise b) repeater coverage is given by the graph. If the coverage after some wait time is not complete the repeater re-sends the package.

I am not in a dense mesh so there are only 3 nearby repeaters listed currently on my repeater.
Assumed the implementation is not totally wrong the suppression ratio shows the potential of this approach. Although there are lots of conditions that reduce the suppression case there is still lots of reasonable flood reduction:

> get flood.suppress
> on, suppressed 151/352 (42%)

Finally let's reconsider the yagi / same mast / topology aspect: the coverage condition should rule out that in such cases a repeater suppresses by the bi-directional reachability check but I need to revise this claim. Did I miss something?

[usrflo]

An explanation of the flood suppression relying on topology knowledge:

[usrflo]

Steps to test this PR:

1. after flashing assure to set the following configs:

set repeat on
set flood.suppress.snr.lo 0
set flood.suppress.snr.hi 9
set flood.suppress.delay.factor 2
set trace.tx.power 10
set flood.suppress on

2. reboot or execute 'discover.neighbors' for a quick neighbor detection

3. wait for at least 15 minutes to collect communication with neighbors and clients

4. evaluate nodes:

Show clients known to your repeater; the repeater covers the flood packages that are relevant for its clients:

> clients
  -> 1D:3665s

Show near repeaters that are part of the topology checks for flood suppression:

> near
  -> near snr_lo=0 cap=5 n=3
meas sent=6 ret=6 edge=6 tmo=0 neg=0 harv=14 unr=0
FC2EFFFE:3927:55
B7C4968A:3724:51
1C1944EF:3857:46

Explanation:

Header — near snr_lo=0 cap=5 n=3
snr_lo — active low SNR threshold; only neighbours with SNR ≥ this count as coverage peers.
cap — coverage cap; only the cap strongest neighbours are owed coverage.
n — number of near neighbours currently found (the lines that follow).

Coverage TRACE health — meas sent=6 ret=6 edge=6 tmo=0 neg=0 harv=14 unr=0
sent — coverage TRACE attempts.
ret — round-trips that came back.
edge — links recorded (returns with SNR ≥ snr_lo) — the measured topology.
tmo — pairs that timed out twice (no link).
neg — pairs cached as no-edge and skipped on per-pair exponential backoff (~2 min transient → ~10 h permanent).
harv — edges/negatives adopted from overheard neighbours' TRACES (passive harvest).
unr — near neighbours this node cannot reach and therefore excludes from protection.

Per-neighbour — FC2EFFFE:3927:55 = HASH:secs_ago:snr (strongest first).

Quick diagnostics:
sent>0 with ret=0 → round trips lost (collisions)
ret>0 with edge=0 → all measured links below snr_lo
sent=0 → no measurement window yet (needs ≥ 2 near neighbours)

Check ingoing and outgoing connections / edges of a specific neighbor repeater:

> reach 1C1944EF
  -> <B7C4968A,FC2EFFFE
>B7C4968A,FC2EFFFE

Check how many flood packages could be suppressed so far:

> get flood.suppress
  -> > on, suppressed 3/6 (50%)

[Alain2019]

@usrflo

I have my doubts.

The scenario that has to be 100% covert is a redundant repeater that is used for local coverage for companions. Those companions can be fixed ones or passer by ones (traffic). For example a repeater that's placed on traffic lights for several underground traffic sensors (sensor nodes or Push Sensor Node - new node type request #3197). And it's wanted that it also works for those that are passing by.

Only floods for repeaters can be suppressed, but I can also imagine that repeater advertisements are not needed to flood so very local. A repeater advertisement is -as far as I understand it- only needed to configure the repeater. The admin doesn't need an extra advertisement while passing by.

[usrflo]

@Alain2019

Your traffic-light scenario is covered by the client-awareness of the implementation. A repeater learns its attached leaf clients automatically: any packet where it is the first hop (empty path) seeds the sender in a 16-slot table (24h freshness) - the underground sensors from their first transmission, a passing companion from its first message. Suppression of an addressed flood (REQ/RESPONSE/TXT_MSG/...) is only allowed when the destination is NOT one of those clients (the command clients lists them). And broadcasts (ADVERT/GRP/...) are never suppressed at all: they could be relevant to the clients.

On adverts: agreed they don't need to fan out far, but a limitation already exists as set flood.max.advert N in mainline - this PR deliberately leaves adverts untouched.

[Alain2019]

@usrflo

A companion that's passing by hasn't send a msg. So it will miss a direct msg. --> important for a "good" repeater to avoid that.

For adverts: I make a distinction between the repeater advertisements and the other nodes. As far as I understand it repeater advertisements are not a problem if missed, but they take up a large portion of the traffic. (Using Probabilistic Flood Forwarding for Advertisement Packets #1223) only for repeater advertisements would be an option also or even a combination off the two.

[usrflo]

@Alain2019,

A companion that's passing by hasn't send a msg. So it will miss a direct msg. --> important for a "good" repeater to avoid that.

In the sending case a companion registers at a repeater as a client so the repeater provides dedicated packages to the companion. Yes, there is a gap turning this around for the receiving case of a (moving) companion. What about an active registration of listening companions? Similar to phones in mobile networks?

For adverts: I make a distinction between the repeater advertisements and the other nodes. As far as I understand it repeater advertisements are not a problem if missed, but they take up a large portion of the traffic.

Good idea; yes I should implement the potential suppression of repeater adverts.

[Alain2019]

@usrflo

What about an active registration of listening companions? Similar to phones in mobile networks?

This means that companion would send quite regular, seems more messages than letting the repeater do it.

Good idea; yes I should implement the potential suppression of repeater adverts.

Thanks