Module fusion 

Sensor fusion: turn loss / burstiness / delay-trend readings into a coding decision, behind a swappable FusionPolicy so the arbitration strategy is chosen empirically rather than hard-coded.

The hard question - when sensors disagree, who wins, and with what hysteresis so the level does not oscillate - is settled by scoring candidate policies over synthetic traces with score_policy and picking the best, then confirming on real links. The score rewards fast escalation (cover loss before it hurts) while penalizing oscillation (level flapping) and average parity overhead.

Structs

ControlDecision

The coding configuration a policy selects.

ImmediateUpConservativeDown

Raise the level immediately (cheap insurance), but only lower it after hold consecutive ticks that all call for a lower level - so a brief dip does not drop protection and the level does not oscillate.

MaxOfSensors

Jump straight to the sensors’ raw target every tick - maximally responsive, but flaps when sensors are noisy.

PolicyScore

Score of a policy over a trace: lower is better.

SensorSnapshot

A fused snapshot of the channel from all sensors.

Constants

QUEUE_BLOAT_MS

Standing-queue delay (ms) above which a rising delay trend is judged self- induced bufferbloat rather than external congestion. ~25 ms of queue we are causing means pace down (the flow window drains it); adding FEC parity would only add wire traffic and deepen the queue.

Traits

FusionPolicy

A strategy that maps a sensor snapshot to a coding decision, carrying whatever state (hysteresis counters, last level) it needs.

Functions

effective_loss

The effective loss the controller protects against: measured loss plus the feed-forward predictors (congestion share, rising delay trend, path shift, backhaul hops, link stress, ECN, reverse loss), clamped to 0..=1. A rising delay trend that is OUR OWN standing queue (self-induced bufferbloat) does NOT add protection - the flow-window pacer drains it; adding redundancy would only deepen the queue - so that bump is suppressed above QUEUE_BLOAT_MS. Both the block-RS parity map and the RLC rate law consume this single number, so the two codes assess the channel identically and differ only in how they translate it into coding parameters.

is_clean

Whether the path is provably clean: no measured loss, no clustered loss, no rising delay trend, and no feed-forward stress (link / path-shift / ECN / reverse-loss / backhaul). A clean link calls for zero protection - the block-RS path ships at Passthrough, the RLC path disables coding - with ARQ the floor if a rare drop slips through before the controller re-arms. Both codes share this predicate so “clean” means the same thing to each.

raw_target

The configuration the sensors alone call for, before any policy-level hysteresis or timing. Feed-forward: a rising delay trend bumps the level up even while measured loss is still low.

score_policy

Run policy over trace and score it. loss_threshold defines a “high loss” sample for the escalation-lag measurement.