Proposal: Probabilistic Flood Forwarding for Advertisement Packets

[ViezeVingertjes]

Large mesh networks experience severe congestion from advertisement floods. Every node broadcasts advertisements periodically (every 6-12 hours), and with traditional flooding, these propagate through the entire network with 100% forwarding probability at every hop.

Proposed Solution

Implement hop-based probabilistic forwarding for flood advertisement packets. Forwarding probability decreases exponentially with hop count, dramatically reducing redundant transmissions while maintaining good network coverage.

Formula: P(h) = 0.308^(h-1) where h = hop count

Results

Based on genetic algorithm optimization across realistic network sizes (25-800 nodes, averaged across all scenarios):

Metric	Current (Baseline)	With Probabilistic Forwarding	Improvement
Transmissions per advert	6,545	452	93.1% reduction
Network coverage	100%	68.2%	Sufficient for adverts
Average max hops	7.4	4.2	43% faster
Efficiency	9.4%	55.8%	6× improvement

Real-World Impact Example

Scenario: Medium-sized mesh network
Network size: 200 nodes
Flood advertisement interval: 12 hours

Calculation of daily advertisement load:

• Each node floods 1 advert every 12 hours = 2 adverts/node/day
• Network total: 200 nodes × 2 adverts/day = 400 advertisements/day

Impact per single advertisement:

• Baseline: 6,545 transmissions per advert
• Optimized: 452 transmissions per advert
• Reduction: 6,093 fewer transmissions (93.1% reduction)

Daily network-wide impact:

Metric	Before (Baseline)	After (Probabilistic)	Calculation
Transmissions per advert	6,545	452	From simulation
Total transmissions/day	2,618,000	180,800	400 adverts × transmissions
Transmission reduction	93.1%	-	(2,618,000 - 180,800) / 2,618,000

This massive reduction frees up airtime for actual messages, dramatically reducing congestion and delays.

How It Works

The forwarding probability decreases rapidly after the first hop:

Hops	Probability	Meaning
0	100%	Source always transmits
1	100%	First hop always forwards (offset formula)
2	30.8%	Aggressive reduction begins
3	9.5%	Most long paths stop here
4	2.9%	Minimal propagation
5+	<1%	Extremely rare

Why This Works:

• Most nodes are reached within 4-5 hops
• Hops 6+ contribute <5% additional coverage but cause 90%+ of redundancy

Tuning

The base parameter can be adjusted based on network requirements:

Base Value	Coverage	Reduction
0.25	~60%	~95%
0.308	68%	93%
0.35	~75%	~90%
0.40	~80%	~85%

[sigram]

This sounds like a very much needed improvement - https://analyzer.letsme.sh/stats shows that repeated adverts use as much as 45% of all transmitted bytes.

[ViezeVingertjes]

This sounds like a very much needed improvement - https://analyzer.letsme.sh/stats shows that repeated adverts use as much as 45% of all transmitted bytes.

Yes, it adds up really quickly. For us in NL it was even more than 50% of the volume and it jammed the whole network at some point. I know that people don't like probabilistic approaches though, but perhaps this opens some discussion with good alternatives, as now we are forced to run repeater firmwares that discard adverts etc. which isn't ideal also.

On a positive note; after the spike were the whole network was congested by adverts, we managed to get enough people to raise their Advert intervals and it has a noticeable effect straight away already.

Or perhaps we could even solve it simpler; by adding max hops to automated flood adverts and keep the option to trigger one without manually if required, who knows.

[wesselah]

This sounds like a very much needed improvement - https://analyzer.letsme.sh/stats shows that repeated adverts use as much as 45% of all transmitted bytes.

Yes, it adds up really quickly. For us in NL it was even more than 50% of the volume and it jammed the whole network at some point. I know that people don't like probabilistic approaches though, but perhaps this opens some discussion with good alternatives, as now we are forced to run repeater firmwares that discard adverts etc. which isn't ideal also.

On a positive note; after the spike were the whole network was congested by adverts, we managed to get enough people to raise their Advert intervals and it has a noticeable effect straight away already.

Or perhaps we could even solve it simpler; by adding max hops to automated flood adverts and keep the option to trigger one without manually if required, who knows.

Adding max hops for automated flood could be ttl or is ttl also the ttl could be adjusted for mesh size this gives you flexibility for the future just as an suggestion

[usrflo]

Consideration of a dynamic advert drop factor versus the proposed static factor:

A dynamic advert drop factor that considers

• the amount of adverts being received (similar to examples/simple_repeater/RateLimiter.h and its use for "discover_limiter")
• or the load on a node (see StaticPoolPacketManager::getFreeCount())

could optimize the overall load of the mesh network: the approach to drop more adverts if load is high and allow more flood hops if load is low seems to more beneficial than a static drop factor (0.308).

A dynamic advert drop ratio that goes up to 100% on a single node could even prevent denial-of-service floods near to the flooding node without disturbing the nodes with distance >= 2 that could continue to work as usual.

So I propose to change the formula P(h) by a dynamic factor (flood rate limiting + node capacity consideration).