Each overlay tunnel carries live simulated telemetry — round-trip latency, jitter and packet loss — that a real SD-WAN edge measures continuously with in-band probes over its encrypted (IPsec/DTLS) transport. The controller reduces each tunnel's telemetry to one composite cost:
S_i = w_L·(latency_i / 300ms) + w_J·(jitter_i / 100ms) + w_P·(loss_i / 15%)
pick candidate = tunnel with min(S_i)
switch active → candidate only if S_active − S_candidate > hysteresis
- Weights — how much each metric matters for the traffic class (e.g. voice weighs jitter heavily, bulk transfer weighs loss).
- Hysteresis — the minimum score improvement required before steering switches paths; without it, two tunnels with near-equal scores would flap back and forth every tick (route flapping), which real controllers actively dampen.
- Brownout buttons — inject a temporary latency/jitter/loss spike on one tunnel, mimicking an ISP outage or congestion event, and watch the controller fail over once the cost gap exceeds the hysteresis margin.
- Firewall gate — every packet is decrypted, inspected against policy and re-encrypted at the midpoint before continuing to the hub, the overlay-security step that distinguishes SD-WAN from a plain best-path router.
- Score-history strip — the lower panel plots each tunnel's composite score over the last ~20 seconds, so a brownout spike (and the controller's reaction to it) is visible as a trace, not just an instantaneous number.
Real-world relevance: this scoring-plus-hysteresis pattern is exactly how commercial SD-WAN controllers (application-aware routing / path steering) keep latency-sensitive traffic on the best available encrypted tunnel without constant path churn. This 2D build re-derives the identical scoring math independently of the 3D version — verified numerically against the same formula (see code comment near computeScore) — and renders it as a top-down schematic instead of a 3D scene: drag the map to pan, scroll/pinch to zoom.