Design decisions

What Atlas does not do, on purpose.

A transport earns trust by being clear about its edges. This page lists the things Nexus Atlas deliberately leaves to other layers or to you — each with the reason it is the right default, what we build when a programme needs the other choice, and what to do meanwhile. These are decisions, reviewed on every release; the comparison page says where alternatives win, and the standards page says which documents each decision follows or departs from.

Decisions, with reasonsEvery entry has an “on request” line
Worked in full

Telemetry and video are carried, not aligned.

A drone sends a video feed and a telemetry stream through the same tunnel. The question every integrator asks: does the frame on the ground describe the same instant as the position record beside it? The honest answer is that a transport cannot know, and Atlas is built so that the answer stays with the system that can.

AIRCRAFT GROUND TELEMETRY · POSITION CLASS recordt = 0 single best link · no hold deliveredt ≈ 20 ms VIDEO · VIDEO CLASS frameexposed t = 0 encoder+100…300 ms spread across all links release bufferhold 120 ms deliveredt ≈ 300 ms skew between the two at 20 m/s the aircraft moves two metres in every 100 ms of that skew the transport cannot see which frame belongs to which record — only the aircraft can
TELEMETRYleaves at once, single best link, no hold — delivered in about 20 ms
VIDEOencoder, then all links, then a 120 ms hold — delivered in about 300 ms
THE SKEWis the sum of those differences, and the transport cannot see which frame matches which record
Not done

Atlas does not align one stream with another.

It never reads a payload, so it does not know that a frame and a record describe the same instant. Each class is carried under its own contract — telemetry spread across links with no hold, position on the single best link, video spread across links and then held 120 ms to remove jitter — and those contracts move the two streams differently on purpose.

Why

Only the aircraft knows which frame goes with which record.

A camera encoder adds between a tenth and a third of a second before the first byte of a frame exists; the telemetry record is on its way immediately. That gap is created before either stream reaches the tunnel, and a transport that equalised its own delay would still deliver the frame with the wrong record beside it. The alignment belongs where the timestamps are: embedded in the video stream as per-frame metadata, which is what STANAG 4609 video does with its KLV track, or carried by both streams from one clock. Atlas carries either unchanged, preserves order inside each stream, and never rewrites a timestamp.

Available

Equal transport delay, declared, for streams that must travel together.

Where a programme wants the transport to keep two streams in the relationship they had when they left the aircraft, one line of class policy does it — companion = "Video" on the telemetry class: the companion class takes the same link plan as the stream it follows and passes through the same release buffer with the same hold, so the two arrive in the order they were sent and with the same added delay. Beside it, the per-class delivery delay is published in the snapshot and the dashboard, so ground software reads the skew instead of guessing it. The sketch below is the companion setting in one picture.

Meanwhile

Timestamp at the source; align on the ground.

Put GPS time on both streams at the aircraft, or embed the telemetry in the video container, and align by timestamp in the ground software. This works through Atlas exactly as it works on a cable: the per-stream ordering is preserved and nothing in the tunnel path depends on the content. For a camera that cannot timestamp, the operations page lists the per-link round trips and the configured hold, which bound the part of the skew the transport adds; the encoder’s own delay comes on top.

AVAILABLE · COMPANION CLASS telemetrycompanion = Video videoas today one link plansame paths, same order one release buffersame hold for both telemetryt + d videot + d equal added delay, order preserved — the aircraft’s own timestamps still decide which frame matches which record
COMPANION CLASStelemetry rides the video’s link plan and release buffer — same delay, same order
Transport

What the data path leaves alone.

Each decision below keeps the data path a transport: it moves datagrams between the links you bonded, and it does not pretend to be the application, the WAN optimiser or the switch.

No retransmission

Loss is repaired by copies and parity, never by asking again.

Not done. The tunnel has no acknowledgements and no resend buffer. Why. A resend across a long or narrow link arrives after the deadline that made the packet useful; duplication across links and Reed–Solomon parity repair loss in one trip, with no return channel. Shipped. Time-diversity repeats for the command class on a single bearer: the same packet sent again a fraction of a round trip later, without acknowledgements, for the moment a node is down to its last link (how repeats work). Meanwhile. Let TCP and QUIC do their own retransmission above the tunnel; give command traffic two links and the duplicate policy.

No acceleration

No TCP proxying, no compression, no payload deduplication.

Not done. Atlas does not terminate TCP, compress payloads or deduplicate content. Why. Each of those reads the payload, and a transport that reads payloads cannot carry end-to-end encrypted traffic unchanged. On request. Header compression for recognised voice flows on narrow bearers, applied to the IP, UDP and RTP headers and nothing else, as a per-link option. Meanwhile. Run the optimiser you already have on either end; Atlas carries its output.

No application awareness

Classification reads marks and flow shape, not protocols.

Not done. The classifier reads DSCP marks, ports, operator flow rules and flow heuristics. It does not parse video, autopilot or sensor protocols. Why. Protocol parsers are the largest attack surface a transport can carry, and every encrypted application stream defeats them anyway. On request. Flow rules already set a class and a precedence level by source address and destination port, so a primary camera outranks a secondary one without either setting a mark; matching on destination address and source port as well, for devices that share one address. Meanwhile. Mark at the source where the device can, or with a firewall rule on the companion computer where it cannot.

No clock synchronisation

Atlas measures round trips, not one-way delay.

Not done. Nodes do not synchronise clocks with each other. Why. Round trips need no shared clock, and a transport that depended on time sync would fail with it. On request. One-way delay estimation over the existing probes, per link, for programmes that need delay equalisation to be exact rather than shared-fate. Meanwhile. GPS time on the platforms that have it; the round trip on the operations page is an upper bound on the delay in either direction.

Layer 3 only

An IP tunnel, not a bridge.

Not done. No Ethernet bridging, no non-IP protocols, no IPv6 inside the tunnel; the underlay speaks IPv6, the inner tunnel is IPv4. Why. A Layer-3 tunnel is what makes per-packet scheduling, classes and multi-hop routing possible; a bridge would carry frames it cannot reason about. On request. IPv6 inside the tunnel for programmes that have moved their platforms to it. Meanwhile. Route into the tunnel; bridge beside it if a legacy protocol needs a wire.

Resilience first

The default strategy does not add bandwidth together.

Not done. Out of the box, Atlas favours a resilient path choice over the summed capacity of the links. Why. Most fleets bond for continuity, not for throughput, and aggregation across dissimilar links costs reordering that a video decoder notices. On request. Nothing to build: aggregation is one of the eight shipped strategies, chosen in one line of configuration, and the measured efficiency is on the bonding page. Meanwhile. Pick the strategy that matches the mission; the dashboard shows what each one is doing.

Whole packets per link

Fragments of one packet always ride one link.

Not done. Striping is per packet or per parity shard, never per fragment. Why. A packet needs all of its fragments; splitting them across links multiplies its loss probability instead of dividing it. On request. Nothing to build; this is the design. Meanwhile. Lower the tunnel MTU where fragmentation itself is the cost, and let the per-link capacity figures drive the stripe.

Security

Three places where “encrypted” needs a second sentence.

The security page states the trust model of each path type. These are the decisions behind it.

Hop-by-hop across relays

A fleet relay can read what it forwards, unless you seal the payload.

By default, multi-hop forwarding through fleet members re-encrypts per hop, and sealing the payload end to end is an opt-in. Why. A relay that cannot read the header cannot make a forwarding decision, and a relay that must open and re-seal every payload for routing would do so anyway; the per-hop model is the honest statement of what a trusted member on the path can see. On request. End-to-end sealing is already shipped as an option; the hosted traversal relays are the other model, and see only envelopes. Meanwhile. Place relays on members you trust with the payload, or turn end-to-end sealing on.

The trade-off. Hop-by-hop keeps per-leg rekeying every 120 seconds and per-neighbour replay protection, adds no bytes, and carries every traffic type, including broadcast, multicast and the FEC class; its cost is that a trusted relay reads the payload and could rewrite the origin field unnoticed. End-to-end sealing ([crypto] e2e) gives a relay nothing to read, uses a non-interactive key with no handshake, no per-pair state and no first-packet latency, binds the sender and the class under the seal so a tampering relay is caught at the destination, and passes through relays that have not enabled it. It costs 67 bytes per packet, so a full-MTU packet becomes two fragments per hop; it covers unicast only; it does not combine with the FEC class; it has no replay window and no forward secrecy of its own, the hop layer providing both per leg; a relay can no longer classify a sealed payload; and both ends must turn it on. Relay CPU is the same either way, since the hop layer is still opened and re-sealed at every hop; the endpoints add one seal and one open.

No negotiation

One cipher suite, one protocol version, across a fleet.

Not done. There is no cipher or version negotiation on the wire. Mixed versions fail loudly. Why. Negotiation is where downgrade attacks live, and a fleet is upgraded as a unit anyway. On request. A different primitive set behind the same handshake is a build-time choice, which is how an accredited or national suite is accommodated; the certification tracks describe the two that programmes ask about. Meanwhile. Treat the fleet as one version; the release notes state the compatibility rule for each release.

Not a firewall

Admission is by key, never by content.

Not done. Atlas does not inspect, filter or log the content of what it carries. Why. Inspection would require reading payloads, and the product promise is that nothing in the path depends on them. On request. Per-member capabilities on the admission record, which of the classes a member may send and whether it may relay, enforced at the queue and the forwarding decision rather than by inspection. Meanwhile. Put the firewall where it belongs, on the tunnel interface of each host, and let Atlas carry what it passes.

Control

Decisions every node makes alone.

No controller is not a slogan here; it is the reason several familiar features are absent.

No controller

No orchestrator, no cloud, no policy server.

Not done. Nothing central exists: configuration spreads by signed epochs over the tunnels themselves, and every node computes its own routes. Why. A controller is the one failure that takes the whole network with it, and the environments Atlas is built for lose their reachback first. On request. The hosted console is the opt-in view for fleets that want one pane; it observes and never commands the data path. Meanwhile. Push configuration from any member; the epoch mechanism carries it to the rest.

No reservation

Priority and floors, not per-flow guarantees.

Not done. Atlas does not reserve capacity per flow and does not admit or refuse flows by a declared rate, the way Deterministic Networking does. Why. Admission control needs applications to describe their flows in advance, which breaks the promise that nothing on the member changes; strict priority with reserved floors protects the command channel without that contract. Done instead. Headroom-aware routing for the command class: nodes advertise the load and the queue wait on their links, and Control routes on a second shortest-path map that counts that load, so a command steers around a relay busy with video while the video keeps its cheapest path; see paths with room. Meanwhile. Size the floors to the command traffic and let video take what remains; the measured behaviour is on the transport page.

Prediction advises

A projected fade never declares a link dead.

Not done. Signal-trend and position prediction bias scheduling decisions; they never mark a link down. Why. Measurement is the only authority that cannot be wrong about the present, and a prediction that could kill a link would eventually kill a good one. On request. Nothing to build; each prediction source is switched on or off in configuration. Meanwhile. Read the prediction page for what advisory means in numbers.

Quotas are costs

An over-budget link still carries traffic when it is the last one.

Not done. A metered link that exceeds its quota is demoted, never disabled. Why. A kill switch on the last remaining path converts a cost problem into an outage. On request. A hard cap, for programmes that prefer losing the link to exceeding the budget; the operations page already shows the ledger. Meanwhile. Let the quota demote; alert on the ledger.

Pinned paths stay pinned

A static path does not adapt, by definition.

Not done. An operator-pinned path is honoured without reaction to conditions. Why. Rehearsed operations need deterministic behaviour more than they need the best path of the moment. On request. Nothing to build; mix pinned flows with adaptive ones in the same fleet. Meanwhile. Pin what must be predictable and leave the rest to the scheduler.

Radio

Atlas sits above the bearers.

The radio is a link. What the radio does on the air is the radio’s business, and the diversity between radios is the defence.

No radio control

No channel, power or waveform decisions.

Not done. Atlas does not tune radios and makes no claim about resisting interference on a single band. Why. The bond works across any bearer that carries a datagram; when one band degrades, continuous quality scoring moves classes to links on other bands, and that is where resilience comes from. On request. Telemetry adapters that read a radio’s own signal figures into the link scores, as already shipped for serial, Wi-Fi, Ethernet and Bluetooth bearers. Meanwhile. Bond radios on different bands; let the diversity do the work.

Hard NAT pairs stay relayed

No port prediction.

Not done. Two endpoints behind endpoint-dependent NATs stay on the relay; Atlas does not guess ports. Why. Port prediction succeeds sometimes and fails silently otherwise; a relayed path that always works beats a direct path that sometimes does. On request. Nothing to build; the relay carries opaque envelopes and the classification is reported per link. Meanwhile. Read the traversal page for which NAT pairs punch and which relay.

Request an evaluation

If one of these decisions is wrong for your programme, say so.

Every entry on this page has an “on request” line for a reason. Bring the case; sequencing is set by real programmes, not by what reads well.