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]

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

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