Proposal: Hop-weighted rebroadcast delay to reduce flooding without breaking self-healing

[Syridian]

Problem

Meshtastic relies on managed flooding for robustness, but in medium-to-large meshes this can cause excessive rebroadcasting, especially for packets that have already traversed multiple hops. Hard hop-based dropping risks breaking mesh self-healing.

Proposal

Introduce an optional hop-weighted rebroadcast delay:

Nodes add a configurable delay to rebroadcast proportional to the number of hops a packet has already traversed. If another node rebroadcasts first, existing duplicate suppression cancels the transmission.

This biases toward shorter paths while preserving flooding as a fallback.

Example logic

rebroadcast_delay =
    base_delay
  + (hop_penalty_ms × hops_already_traversed)
  + random_jitter

Benefits

• Reduces RF congestion and collisions
• Naturally favors shorter / higher-quality paths
• Preserves self-healing (no packet drops)
• No routing tables or topology knowledge required

Compatible with partial deployment

• Suggested config (optional, disabled by default)
• hop_delay_enable (bool)
• hop_delay_ms (default ~50 ms)
• hop_delay_max_ms (default ~300 ms)

Why this fits Meshtastic

• Uses only packet-local information
• No new protocol messages
• No coordination required
• Aligns with existing delay + suppression model

Acknowledgement of related discussions and rationale for this approach

Several prior Meshtastic GitHub discussions have explored hop-based controls to reduce excessive flooding, including proposals to:

• drop packets whose original hop limit exceeds a local threshold
• refuse to forward packets from nodes more than N hops away
• clamp or override hop limits at router nodes (e.g. discussions [Feature Request]: Limit messages forwarded by routers depending of max hops settings or hops used #4764, [Feature Request]: Option to limit traffic based on original hop settings #4060, [Feature Request]: Enforced hop limits on packet relay for repeaters and routers #3258)

These proposals correctly identify mesh congestion caused by high hop-count packets as a real problem, especially in larger or denser meshes.

However, those approaches primarily rely on hard filtering or packet dropping, which introduces several risks:

• reduced redundancy and resilience
• creation of “mesh cliffs” where connectivity fails abruptly
• harder-to-predict failure modes during partial outages
• reduced self-healing when topology or RF conditions change

Why hop-weighted delay is a safer alternative

This proposal takes a different approach: instead of enforcing policy by dropping packets, it introduces a soft preference mechanism using hop-weighted rebroadcast delays.

Key differences:

Delay, not deny
Packets are never dropped due to hop count alone. Flooding remains intact as a fallback.

Preserves self-healing
If closer or better-placed nodes fail to rebroadcast, higher-hop routers will still forward the packet after a bounded delay.

Naturally favors shorter paths
Nodes closer to the source rebroadcast earlier and suppress redundant transmissions without requiring routing tables or topology awareness.

Avoids mesh cliffs
Connectivity degrades gracefully instead of failing at arbitrary hop boundaries.

Compatible with partial deployment
Nodes that do not implement or enable this feature continue to behave normally.

Relationship to prior proposals

Rather than replacing earlier ideas, this mechanism can be seen as:

• a lower-risk alternative to hop-based dropping
• a first step that may reduce the need for hard hop limits
• a solution aligned with Meshtastic’s existing delay-and-suppression model

This approach attempts to achieve the same goals discussed in prior threads — reduced congestion and improved efficiency — while minimizing the downsides that led to concerns in those discussions.