Adaptive FEC at the Graphiant Edge

WAN traffic increasingly rides paths we don’t own. Broadband last miles, cable uplinks, and middle-mile transit between metros all drop packets, and they do it in the way that hurts real-time traffic most: intermittently, in bursts, at rates that barely register in an average-throughput graph. A tunnel can sit at 0.3% loss for an hour and look healthy on a dashboard. At the same time, the EF-class voice and interactive video riding inside it accumulate dropouts and jitter that users notice immediately.

At fleet scale, the problem changes character. A single hub fans out to hundreds or thousands of paths, loss events are uncorrelated across paths and across time, and we can’t fix the underlying circuits; they belong to carriers we don’t control. What we can control is what a Graphiant edge does about loss on the paths it’s handed. The operational constraint is that the obvious fix — send more data so a loss doesn’t matter — collides with the one resource WAN economics actually cares about: bandwidth on reliable circuits is expensive, and any recovery scheme that taxes it uniformly across the fleet doesn’t survive contact with a finance review.

This post describes how the Graphiant edge recovers from loss on loss-sensitive traffic classes, why we built it as an adaptive Forward Error Correction (FEC) system rather than the packet-duplication approach common in SD-WAN, and where the tradeoffs are.

Adaptive FEC for your enterprise can be enabled to protect Gold-class [ SLA Class - EF ] traffic on lossy links as mentioned here .

Redundancy in space vs redundancy in code

There are two ways to make a packet survive a lossy path, and they differ in where the redundancy lives.

Packet duplication adds redundancy in space. You transmit each packet twice (or more, but we’ll assume two here), over independent paths, and the receiver takes whichever copy arrives first. Recovery is guaranteed for any loss confined to a single path, and it’s instantaneous, because the surviving copy is already in flight. The cost is a full second copy of the traffic and a hard requirement for path diversity.

FEC adds redundancy in code. You compute parity over a block of source packets and transmit the parity alongside the data. A block of N source packets plus K repair packets lets the receiver reconstruct up to K erasures anywhere in that block. Recovery is statistical — it holds up to the code’s capacity and fails beyond it — but the cost is only the parity overhead, and it needs no second path.

That distinction is the whole argument. Duplication buys certainty against single-path loss at a fixed, high price. FEC buys probabilistic recovery at a price you can tune to the loss you’re actually seeing at a point in time. At the scale of one end-to-end path, either is defensible. Across a fleet, the pricing model decides it.

Why packet duplication hits a wall at fleet scale

Duplication is good at what it does. It recovers with zero added latency, it survives the total loss of a path because the copy is on a different one, and it is trivial to reason about: sequence, duplicate, de-dupe. For a small number of ultra-critical flows on sites with reliable path diversity, it’s a fine strategy.

The wall is bandwidth, and it’s structural rather than incidental. Duplication imposes a flat 100% overhead on every protected flow, and it imposes it unconditionally — the second copy goes out whether the path is dropping 5% or 0%. You pay the worst-case cost continuously, everywhere protection is enabled, in exchange for coverage you need only during the fraction of time a path is actually degrading.

Two consequences follow directly. First, the overhead does not scale down when the network is healthy, which may be most of the time on most tunnels; a fleet running duplication carries a permanent doubling of its protected traffic to ensure against loss that, in aggregate, is intermittent. Second, duplication is inapplicable wherever path diversity is absent. A single-uplink edge site has nowhere to send the second copy, so the mechanism that provides all of duplication’s value isn’t available — and single-uplink sites are common in exactly the branch-scale deployments where loss recovery matters.

Duplication, in other words, prices its protection at the worst case and requires an assumption (path diversity) that a large fraction of the fleet can’t satisfy. Both are disqualifying as a default.

Encoding in the tunnel egress path

The Graphiant approach places FEC encoding in the egress path of an end-to-end (E2E) tunnel — the IPsec tunnel between a sending edge and one or more receiving edges. It runs as an egress feature and operates on traffic classes that care about loss. By default, that’s Gold/EF-class traffic only; the set of protected classes is configurable, so the operator decides how much of the flow to cover rather than paying to protect bulk transfers that already have their own end-to-end recovery.

The pipeline is worth walking through, because the ordering relative to encryption matters:

FEC encoding happens after ESP encryption on the sender, and decoding happens before decryption on the receiver. This is a deliberate placement with a concrete security consequence: the FEC layer never sees plaintext, so it adds no exposure to customer data. The parity is computed over already-encrypted payloads, and the repair packets carry nothing the tunnel didn’t already protect.

The encoder inserts a small FEC source header between the tunnel header and the ESP header, marks the packet’s block membership and sequence, and otherwise forwards it unchanged; the repair packets are generated per block. The only steady-state cost on the data path is the header itself, which reduces the E2E MTU by 12 bytes. That is the entire fixed tax; everything else about the overhead is dynamic, and that’s the power.

A receiver-driven control loop

The interesting engineering is not the codec — block erasure coding is well understood in computer science and networking — it’s the control loop that decides how much redundancy to run. The design puts the measurement where the ground truth actually is: at the receiver.

The receiver watches three quantities per monitoring period: how many FEC-protected packets it should have received, how many it did, and how many it could not repair because the redundancy in force wasn’t sufficient. That third number is the signal that matters. It’s not raw loss — it’s loss that the current protection level failed to cover, which is precisely the thing you want to drive redundancy up or down. Raw path loss tells you the path is bad; unrepairable loss tells you whether you’re currently doing anything about it.

From those measurements, the loop steers the sender along a discrete ladder of redundancy levels, and it steers asymmetrically:

• Step up fast. If the ratio of unrepairable losses to received packets in a single period exceeds a threshold, the receiver immediately requests the next redundancy level up. One bad period is enough, because unrepaired loss is already hurting the application.

• Step down slowly. Only if the ratio of total observed loss — repaired plus unrepaired — stays below a lower threshold for a configured number of consecutive periods does the receiver request a step down. Relaxing protection is treated as the risky move and gated behind sustained evidence that the path has genuinely recovered.

The receiver keeps re-sending its request each period until the level it observes matches the level it asked for, so the loop is robust to a lost or reordered request. Concretely, the current design runs the monitoring period at roughly one second and takes a decision only once a minimum packet count has accumulated in the period. Hence, the ratio is statistically meaningful, and requires on the order of ten clean consecutive periods before it will step down a level.

That asymmetry is deliberate hysteresis. Fast up, slow down damps oscillation: the loop reacts to degradation in a single period but won’t chase transient quiet back down and then get caught out by the next burst. It’s the same instinct as a well-behaved congestion controller, applied to redundancy instead of rate.

The redundancy ladder

The levels are discrete, not continuous, and they map a source-to-repair ratio onto a block geometry. Representative rungs run from a light 10% level — ten source packets protected by a single repair packet, enough to reconstruct any single erasure in a block of eleven — up through 25%, 33%, 40%, and 50%, to a heavy 60% level of roughly five source packets protected by three repair packets, which tolerates up to three lost packets in an eight-packet block for genuinely degraded paths.

Two properties of the ladder do real work. Discreteness keeps the control loop simple and the sender’s job cheap: it holds one level per channel and moves between a small, fixed set of block geometries rather than recomputing a continuous parameter. And the ladder bottoms out at a zero level—a protected channel that runs no repair packets at all. An enabled FEC channel on a healthy path therefore costs nothing beyond the 12-byte header until unrepairable loss actually appears. Protection is armed everywhere it’s configured, but it spends bandwidth only where and when loss demands it.

The bandwidth mathematics

This is where the two approaches separate quantitatively.

Duplication’s overhead on protected traffic is 100%, flat, always. There is no state of the network in which it is less, because the second copy is unconditional.

Adaptive FEC’s overhead is the redundancy level currently in force, which the loop holds as low as the observed loss allows. On a healthy tunnel it sits at the zero level — effectively no overhead. On a tunnel seeing the low-percentage random loss that dominates real paths, it sits near the 10% rung, because one repair per ten source packets already reconstructs the isolated single-packet drops that random loss produces. Only genuinely bad paths climb to the 40–60% rungs, and even at the top of the ladder the overhead is 0.6× the traffic — well under duplication’s 1.0×.

Now multiply across the fleet. Duplication’s aggregate cost is the protected traffic doubled on every tunnel where it’s enabled, indefinitely. Adaptive FEC’s aggregate cost is the loss-weighted average redundancy across the fleet — and because most tunnels are healthy most of the time and rest at the zero level, that average stays close to zero, spiking only on the specific paths and during the specific windows that are actually degrading. In the common case, the difference in WAN bandwidth consumed can be significant.

Duplication pays the worst case everywhere, always; adaptive FEC pays the actual case, locally, only when loss appears.

Where duplication benefits

An honest comparison has to concede where duplication is useful, because those cases are real and they shape where you’d still reach for it.

Two of those rows matter most. Duplication recovers with no added latency, while FEC recovery costs a small block-completion delay plus decode time and gives up on a block after a timeout — so for a small, latency-critical flow on a site that does have path diversity, duplication can be the better tactical choice. And duplication survives a full path blackout, because the copy is on a different circuit; single-tunnel FEC cannot recover if the whole path drops, since the repair packets ride the same path as the data.

These are not reasons to prefer duplication as the fleet default. They’re reasons the two mechanisms are complementary: adaptive FEC as the general-purpose, bandwidth-efficient protection for loss-sensitive classes across every tunnel including single-uplink sites, with duplication held in reserve for the narrow set of flows where zero-latency recovery or blackout survival justifies the fixed 2× cost and the path-diversity assumption holds.

Summary

The engineering result is a loss-recovery layer with a few concrete properties. It protects the traffic classes that care about loss and leaves the rest untouched, so the customer pays only for coverage they’ve chosen. Its overhead is proportional to observed unrepairable loss rather than fixed, and it falls to essentially zero on healthy paths, so fleet-wide bandwidth cost tracks actual conditions instead of the worst case. It works on a single path, so it covers the single-uplink sites that duplication structurally cannot. It sits after encryption on the sender and before decryption on the receiver, so it adds no exposure to customer data. Its control loop measures the one signal that reflects whether protection is currently adequate—unrepairable loss at the receiver—and steers redundancy with fast-up, slow-down hysteresis that reacts within a period without oscillating.