Every link probed on its own clock (250 ms default), RTT smoothed by EWMA (α = 0.2), loss windowed, plus sequence numbers riding real data fragments so data-path loss is measured directly. Radio adapters add RSSI and buffer-depth — signal before symptoms.
Honest comparison
Where Atlas wins. Where it doesn’t.
Nine alternatives, compared by mechanism rather than adjective — and every section ends with what the alternative does better, because a comparison without concessions is an advertisement. Categories describe product classes; your advisors can verify every row against the rest of this site.
Detection mechanics
First, the part everyone hand-waves.
“Fast failover” claims are meaningless without the detection math. Here is Atlas’s, so the rows below have a denominator.
Load shifts continuously in proportion to measured quality on a typically configured 0.1–0.75 s cadence — this is what makes degradation survivable, and it needs no link to “fail” first. A response cadence, not a universal recovery guarantee.
Five consecutive missed probes ≈ 1.25 s at defaults; tuned profiles (50 ms × 3 ≈ 150 ms) exist and are labeled tuned. By the time a link is declared dead, the traffic usually left seconds ago — that’s the point. Tuned profile
Failover is per-packet beneath the tunnel: applications hold one connection to one interface, so nothing reconnects, renegotiates or re-authenticates when paths change.
The nine
Alternative by alternative.
Jump to: SD-WANMPTCPWireGuardBonding appliancesOverlay networksSingle-constellationDIYMPLSStatus quo
SD-WAN suites enterprise WAN platforms
Architecturally opposite on the one axis that matters here: SD-WAN routes policy through a central orchestrator; Atlas has no controller to buy, host, reach or lose. SD-WAN failover is predominantly per-flow against thresholds — sessions move when a link crosses a line; Atlas decides per packet against continuous quality. And SD-WAN assumes enterprise WAN bearers; Atlas bonds anything that presents IP, down to a 64 kbps serial radio.
Where they’re stronger: years of WAN analytics, application-aware policy at enterprise scale, native SSO/directory integration, and a managed ecosystem your IT department already speaks. If your problem is branch offices and SaaS steering, buy SD-WAN.
Multipath TCP kernel multipath
MPTCP multipaths TCP flows only — UDP, and with it most C2, telemetry, voice and video transports, ride a single path. It requires MPTCP-aware endpoints (or proxies) end to end, subflow scheduling reasons about round-trips rather than link quality vectors, and there is no encryption, no mesh, and no story for a serial radio. Atlas multipaths everything IP at Layer 3, encrypted, with loss/jitter/capacity in the cost model.
Where it’s stronger: it lives in the mainline kernel, adds zero userspace hops for TCP throughput aggregation, and is exactly right for phone-to-server TCP bonding inside one administrative domain.
WireGuard the closest relative
The kinship is deliberate: Atlas inherits the same cryptographic family — Noise IK, Curve25519, ChaCha20-Poly1305 — and the same one-interface mental model. The difference is everything above the crypto: WireGuard sends to one endpoint per peer at a time (roaming replaces the address; it never uses two at once), has no link measurement, no scheduler, no classes, no mesh routing. Atlas is what you get when the tunnel itself understands that there are five paths and that they differ. Overhead is honest on both sides: WireGuard’s 32 bytes to Atlas’s 44 per fragment (72 on-wire with UDP/IP) — the extra 12 buy fragmentation, link identity and scheduling metadata.
Where it’s stronger: in-kernel data plane with roughly 3–5× the single-stream throughput ceiling of any userspace crypto path, six years of production hardening, mainline inclusion, and a massive audit surface. One good link and no bonding requirement? WireGuard is the right answer, and we’d say so in the meeting.
Cellular bonding appliances bonding routers & cloud reconstitution
The appliance model bonds cellular well and stops there: the bond terminates in the vendor’s cloud (your traffic’s availability now includes theirs), the hardware is the product (per-site boxes, per-box licences), and dissimilar bearers — serial radios, mesh segments, VSAT beside LTE — are at best exotic add-ons. Atlas is software on hardware you already own, terminates wherever you say, and treats a 64 kbps radio and a gigabit fiber as equally legitimate citizens.
Where they’re stronger: turnkey — SIMs in, video out — with global support channels, broadcast-grade workflows, and regulatory certifications on the box itself. A news van with a deadline should probably keep its appliance.
Mesh overlay networks identity-first connectivity fabrics
The overlay generation solved reachability beautifully — identity-keyed peers, NAT traversal, relay fallback — and Atlas’s traversal stack shares that shape. But their relays exist to reach, not to bond: one path carries the session, failover is a reconnection, and link quality is not a first-class concept. Atlas holds relay and direct paths in the same scheduler simultaneously, and its coordination plane (signed relay maps, deterministic election) is designed to keep working when the vendor’s cloud — or any cloud — is unreachable.
Where they’re stronger: onboarding measured in seconds, SSO out of the box, enormous installed bases, and free tiers. For connecting laptops to servers over good internet, they are excellent — that was the problem they set out to solve.
Single-constellation satellite one very good link
A modern LEO terminal is a genuinely good link — and exactly one of them. One operator’s network, one regulatory posture, one band to fade in weather or worse. The honest fix isn’t a better dish; it’s the pattern where no single operator is load-bearing: bond the LEO terminal with a second constellation, a GEO VSAT, cellular — anything with a different failure domain. the playbook ↗
Where it’s stronger: raw price-per-megabit and setup time, nothing on this page touches it. The argument was never against the link — it’s against it being alone.
DIY — WireGuard + scripts the honest competitor
Every engineer’s first instinct, and it teaches the right lesson: the tunnel was never the hard part. The detection-and-decision layer is — probe cadences that don’t lie on slow links, hysteresis that doesn’t flap, per-packet scheduling, session survival across path changes, and the four a.m. edge cases. VRRP-style failover converges in seconds; handshake re-establishment adds more; and every improvement you script is a product you now maintain. Atlas is that layer, already built, and continuously exercised by an automated test estate that puts real daemons through the failure modes — not unit tests alone.
Where it’s stronger: zero licence cost, total control, and a fine answer for two static sites with patient traffic. If the scripts are working and nobody’s life depends on the failover window, carry on — sincerely.
MPLS / private circuits the contractual gold standard
A private circuit buys a contract, not a mechanism: the SLA pays out after the outage it didn’t prevent. Provisioning is measured in weeks and the endpoints don’t move — which disqualifies it from every mobile, temporary or contested scenario on this site. Where circuits exist, Atlas happily bonds them with everything else; the circuit becomes one very good link instead of the single point of contractual failure.
Where it’s stronger: contractual guarantees, mature procurement, regulatory acceptance in industries that require exactly that piece of paper. Fixed sites with compliance-driven networking keep their circuits — and bond them.
The status quo one link and hope
No software to install, no concepts to learn, and a single point of failure with excellent uptime right until the moment that defines the mission. Every number on this site is ultimately compared against this baseline: one link’s bandwidth versus the sum; binary outage versus gradual degradation; 2% loss versus 0.0008% across three independent 2% links in broadcast mode.
Where it’s stronger: simplicity, and honesty demands we say it — if the mission genuinely tolerates the outage, one good link and a competent operator beat any system nobody configured correctly.
Per-flow vs per-packet
The one row we can show you instead of assert.
The SD-WAN row turns on a single mechanical difference: when the decision is made, and against what. Failover in that generation is predominantly per-flow against thresholds; Atlas decides per packet against continuous quality. Kill a link and both look similar. Degrade one gradually — the case the comparison actually turns on — and the two responses take different shapes.
Same three links, same offered traffic, two selection policiesSimulation
Degrade the microwave link
—Degrading link's share — per-flow · per-packet
—Biggest single move in any link's share
—Late or lost since reset — per-flow · per-packet
What you're watching: a simulation — the quality score, the packet counts and the threshold value are illustrative, not measured. Per-flow selection against a threshold is a legitimate design and not a strawman here: it holds a session on one path, keeps scheduler state proportional to flows rather than packets, makes capacity accounting exact because a flow is either on a link or it isn't, and once it has moved, none of your traffic is on the bad link at all. Its costs are the two things the panes report — nothing moves while the link rots, then everything on it moves at once, and a whole link's capacity leaves the bond in one step. Per-packet selection has no step and keeps every link earning, and pays for that in reordering the tunnel resequences and in a small residual it deliberately leaves on a degraded path so it can still be measured. Watch a whole cycle rather than a moment: each policy is ahead somewhere. Real products in either camp blend the two, and the hold-down modelled on the left is flap damping, not sloppiness.
The disclosure that keeps this page honest: Nexus Atlas is pre-release software from a small European team — no certifications yet, no public downloads yet, support directly from the engineers. Every row above compares mechanisms we ship against product classes at their typical best; when a specific product in your evaluation contradicts a row, bring it to the conversation and we’ll correct the page or concede the point in writing.