Forward Error Correction (FEC) is a technique in which a sender adds redundant parity data to a transmission so the receiver can reconstruct any packets lost along the way, without asking the sender to retransmit them. On lossy SD-WAN links, FEC trades a modest bandwidth overhead for a smoother, more reliable application experience.
Key takeaways
- FEC adds parity packets so receivers rebuild lost packets, no retransmit.
- Best suited to real-time, latency-sensitive traffic like VoIP and video.
- Configured in an SD-WAN forwarding profile, on both sender and receiver.
- Smaller parity groups recover loss more reliably but cost more overhead.
- VOS can start and stop FEC automatically based on SLA and link usage.
On this page: Why it mattersHow it worksTypesFEC & VersaFAQ
Why is FEC important?
Real-time traffic – voice calls, video conferencing, and other latency-sensitive flows – cannot tolerate the delay of detecting a lost packet and waiting for it to be retransmitted. By the time a retransmission arrives, the moment it was needed for has passed, which is why a dropped packet in a VoIP call shows up as a clipped syllable rather than a brief pause.
FEC matters because it recovers from loss proactively instead of reactively: the sender ships redundant parity data alongside the real traffic, so the receiver can reconstruct a lost packet the instant it notices the gap, with no round trip back to the sender required. This matters most on the WAN links carrying SD-WAN traffic between branches and cloud – broadband, LTE, and other circuits more prone to loss than a dedicated private line. FEC is commonly recommended for sites reporting choppy VoIP quality.
What is FEC?
At the packet level, FEC works by having the sender generate a parity packet for every nth data packet it transmits, and send both across the link. The receiver tracks sequence numbers; if nothing was lost, it discards the parity packet. If a data packet is missing, the receiver uses the parity packet’s redundant information to reconstruct it on the spot – no request back to the sender, no retransmission delay.
The parity ratio – how often a parity packet is generated – trades protection against overhead. One parity packet for every three data packets adds roughly 33 percent overhead but sharply improves delivery odds: on a path with 5 percent uniform packet loss, the probability that three packets all arrive rises from about 86 percent without FEC to about 99 percent with it. A wider group of six packets cuts overhead to about 16 percent for a smaller, still meaningful, gain.
Types of FEC
FEC is applied at more than one layer of the stack, and the layer determines what “error” it corrects. Physical-layer FEC is embedded in modems, radios, and optical transceivers, correcting bit errors introduced by the medium itself using coding schemes such as Reed-Solomon, convolutional, or low-density parity-check (LDPC) codes. Codec-level FEC is built into voice and video codecs, adding redundancy inside the media stream so the codec can conceal small losses on its own. Packet-level (network) FEC operates above the transport layer – the type used in SD-WAN overlays, where a parity packet recovers an entire lost IP packet rather than corrupted bits, protecting traffic across whatever mix of broadband, MPLS, and LTE/5G links carries it.
These types are complementary, not mutually exclusive: a voice call can run codec-level and packet-level FEC at once, though stacking both adds less than either alone.
FEC & Versa
Versa implements packet-level FEC as an SD-WAN traffic-steering feature, configured in a forwarding profile – Configure Forward Error Correction for SD-WAN Traffic Steering covers the sender and receiver settings, both required – then associated with a policy rule, as covered in Configure SD-WAN Traffic Steering. The Versa Operating System (VOS) can start sending FEC parity packets automatically when a link goes SLA-non-compliant and stop them based on circuit utilization, and can duplicate parity packets onto an alternate circuit so recovery data doesn’t add to congestion on an already-struggling link.
By default, VOS generates one parity packet per four data packets, tunable from 1 to 32. The Versa SD-WAN Design Guide recommends FEC for small, latency-sensitive packets such as voice or point-of-sale traffic under roughly 500 bytes, advises against LTE circuits, and pairs it with packet replication – FEC for single-path branches, replication where multiple paths justify duplicating traffic.
Frequently asked questions
What is the difference between FEC and packet replication?
FEC generates one parity packet per group of data packets, at modest bandwidth cost. Packet replication duplicates every packet across multiple paths instead, tolerating heavier loss but needing a branch with more than one active WAN path.
Does enabling FEC add latency?
A small amount. Recovering a packet from parity data can require buffering the packets that follow it until the parity arrives, then reordering them. Versa lets you disable receiver-side reordering or shrink the parity group to reduce buffering.
When should I use FEC instead of retransmission?
Use FEC for real-time traffic – voice, video, and other latency-sensitive flows – where waiting out a retransmission cycle defeats the purpose. FEC reconstructs the lost packet proactively, before a request-and-resend round trip could ever complete.
What does FEC cost in bandwidth overhead?
It depends on the parity ratio configured. A parity packet every three data packets costs about 33 percent extra bandwidth; every six packets costs about 16 percent. Smaller groups recover loss more reliably but consume more circuit capacity.
Can FEC be used on any link type?
It applies to Layer 3 SD-WAN traffic steering, and Layer 2 as well since Release 22.1.1, but isn’t advisable everywhere. Guidance discourages FEC on LTE circuits, since bursty wireless loss undermines its per-group model, and favors it for small packets under roughly 500 bytes.
More on FEC
If you want to learn more, these are sources we trust.
| IETF RFC 5109: RTP Payload Format for Generic FEC | IETF RFC 6363: FEC Framework |
|---|---|
| The IETF standard for carrying generic FEC data inside RTP streams – the basis for FEC in real-time voice and video. | The IETF’s general framework for describing and signaling FEC schemes across applications. |
Related terms
If you’re reading about FEC, these are worth looking at next.
| SD-WAN | Virtual Routing and Forwarding | Next-Generation Firewall |
|---|---|---|
| The traffic-steering fabric FEC is configured within – dynamic path selection across broadband, MPLS, and LTE/5G links. | The forwarding-table technology keeping per-tenant routes isolated on the same VOS appliance that runs FEC. | The integrated policy engine applied alongside SD-WAN traffic steering on the same appliance. |