We in Denmark - as in many other areas - are beginning to see issues with hitting the 10% duty cycle limit.
Regions are great, loop detection is great, and set flood.max & flood.max.unscoped is also great.
Problem
- flood.max currently applies globally or to region scopes, that new users may not be aware of.
- Networks transitioning from 1-byte prefixes to 2-/3-byte prefixes may want different propagation limits.
- Legacy 1-byte traffic often doesn't need to travel as far as modern routed traffic.
It should be possible for a 1 byte companion to go on Public channel with no region and get a reply from nearby nodes in case of an emergency, while preventing these messages to be propagated too far from the local area.
While set flood.max and flood.max.unscoped could be used, I would argue, that to prevent DX'ed messages during tropo ducting, we may have to use too small a number for set flood.max and flood.max.unscopeds, than what is actually best for the regional mesh.
For example: During the past weekend, Denmark was flooded with messages from other countries because of tropo ducting, leading to issues with max air time.
The vast majority of these packets were 1 byte paths.
So, a greater balance could be achieved, if there was a way to specifically limit the propagation of 1 byte paths.
Proposed solution:
Add independent configuration values, for example:
- flood.max.1byte
- flood.max.2byte
- flood.max.3byte
With this, we could set one number for set flood.max that was based on the actual needs in our region, and a lower number for flood.max.1byte.
Benefits:
- Limits long-distance propagation of legacy traffic.
- Lets operators encourage migration toward longer prefixes without breaking compatibility.
- Reduces unnecessary retransmissions and airtime consumption.
- Remains backward compatible if unspecified values default to the existing flood.max.
Basically, this is about controlling each problem with the control for that specific problem instead of trying to fix one issue with a tool not built for that:
- set flood.max: Absolute max for propagation of any packet
- flood.max.unscoped: Max for propagation of unscoped packets
- The new kid on the block: Max for propagation of 1byte clients
We in Denmark - as in many other areas - are beginning to see issues with hitting the 10% duty cycle limit.
Regions are great, loop detection is great, and set flood.max & flood.max.unscoped is also great.
Problem
It should be possible for a 1 byte companion to go on Public channel with no region and get a reply from nearby nodes in case of an emergency, while preventing these messages to be propagated too far from the local area.
While set flood.max and flood.max.unscoped could be used, I would argue, that to prevent DX'ed messages during tropo ducting, we may have to use too small a number for set flood.max and flood.max.unscopeds, than what is actually best for the regional mesh.
For example: During the past weekend, Denmark was flooded with messages from other countries because of tropo ducting, leading to issues with max air time.
The vast majority of these packets were 1 byte paths.
So, a greater balance could be achieved, if there was a way to specifically limit the propagation of 1 byte paths.
Proposed solution:
Add independent configuration values, for example:
With this, we could set one number for set flood.max that was based on the actual needs in our region, and a lower number for flood.max.1byte.
Benefits:
Basically, this is about controlling each problem with the control for that specific problem instead of trying to fix one issue with a tool not built for that: