WAN Smoothing, FEC & Sub-Tunnels

Part Five: WAN Smoothing

The topic

WAN Smoothing creates a single, jitter-free data stream by duplicating packets across multiple WAN links and using whichever copy arrives first; the later copies are discarded. Because a redundant copy is always in flight on another path, the loss of any single link, or sporadic packet loss on one link, causes zero interruption and zero delay to the receiver. It is the most aggressive loss-and-jitter protection SpeedFusion offers, and it is built for real-time traffic that cannot tolerate any disruption: VoIP, video calling, telemedicine, live broadcast, mission-critical SCADA.

Smoothing is configurable in levels, and Peplink’s own SpeedFusion Whitepaper defines them by how much total bandwidth they consume relative to the original traffic: Normal ≤ 2×, Medium ≤ 3×, High ≤ 4×, and Maximum, which scales with the number of active WAN-to-WAN connections and can go higher still. In overhead terms that is roughly +100% (Normal) to +300% (High), and up to +400% or more at Maximum. That is not a typo, at the top end you are sending each packet several times over.

How it works on Peplink

Inside the SpeedFusion tunnel, the sending endpoint replicates each packet onto multiple active links. The receiving endpoint takes the first copy of each packet to arrive and throws away the duplicates, presenting the application with a clean, in-order, loss-free stream. The benefit comes entirely from path diversity: when copies travel different physical links, a loss or spike on one link is invisible because the copy on another link arrives fine. This is why smoothing is described as “better with more than one WAN”, more accurately, its entire value comes from having more than one independent path.

 WAN Smoothing, duplicate copies cross multiple links and the first to arrive wins; its value comes entirely from having more than one path.

The cost is by far the highest in the catalog. At Normal you roughly double the traffic (about +100% overhead); at High you reach about 4× (about +300%); at Maximum it climbs with the number of active links. This is why it is never a default and should be applied deliberately, ideally on a dedicated sub-tunnel carrying only the real-time traffic that needs it, never the whole connection. Pick the lowest level that actually clears the loss, then stop.

Why it matters

Smoothing is the feature customers ask for by name because it sounds like the premium option, and it is easy to over-apply. Understanding that its value is path diversity, and its cost is doubled bandwidth, lets you steer the conversation to the right tool: smoothing for multi-WAN real-time traffic that genuinely cannot tolerate a single lost packet, FEC for lossy links where you want recovery without paying double, and neither for ordinary traffic that bonding alone handles fine.

Field note

When a customer has good reliability but complains of delay after you enable smoothing, step the level down (High → Medium → Normal), trim the jitter buffer, and consider FEC instead for micro-loss. Maximum smoothing on wildly mismatched links (say 30 ms Ethernet plus 600 ms satellite) inflates the reorder buffer and adds latency; use cut-off latency to fence the slow link out of the real-time sub-tunnel.

Part Six: Forward Error Correction (FEC)

The topic

Forward Error Correction is the cousin of WAN Smoothing that consumes far less data. Where smoothing duplicates whole packets, FEC adds a modest number of parity packets to the stream. If a data packet is lost in transit, the receiver reconstructs it from the parity by interpolation, no retransmission, no waiting for an acknowledgment, no round-trip delay. It is the middle ground between plain bonding (no protection) and full smoothing (total duplication), and for most real-world loss it is the right first reach.

 FEC, reserve (parity) packets let the receiver rebuild lost packets by interpolation, recovering loss without retransmission and at a fraction of smoothing’s overhead.

How it works on Peplink

The sending endpoint computes parity packets across groups of data packets and sends them alongside the data inside the SpeedFusion tunnel. The receiving endpoint, if it is missing a data packet, uses the parity to rebuild it. Protection is configurable in Low / Medium / High levels, and there is also an Adaptive FEC mode that varies its protection automatically with the measured loss on the link. The overhead numbers are far gentler than smoothing’s: Peplink’s SpeedFusion Whitepaper puts standard FEC at 13.3% (Low) and 26.7% (High) additional bandwidth, and Adaptive FEC runs about 6–20%, spending bandwidth only when there is loss to correct (roughly a 6–27% band across the family). A useful rule: start with Adaptive FEC or Low, and step up only when you have measured that the loss is not being cleared, because the higher levels add overhead for diminishing returns.

FEC is ideal for real-time traffic on links with measurable but moderate loss: a single cellular WAN that drops packets sporadically, or a Starlink link during weather events. It is frequently paired with sub-tunnels so you apply it only to the traffic that benefits, rather than to the whole connection. Compared with WAN Smoothing it is dramatically cheaper, roughly 6–27% versus +100–400%, which is why it is almost always the first tool to reach for and smoothing is the last.

Why it matters

FEC is the feature that resolves most “the call is choppy” problems at a sane cost. Because it works on a single link and recovers loss without retransmits, it improves real-time quality on exactly the connections, cellular, satellite, marginal cable, where retransmit-based recovery would add unacceptable latency. It is also the correct answer to the single-WAN smoothing question in Part Five: when there is only one path, FEC gives you loss recovery; smoothing gives you almost nothing.

Field note

FEC’s overhead is real and CPU cost is higher than smoothing’s on the encoding side, so plan for adequate router horsepower in FEC-heavy roles. And remember the limit it shares with all SpeedFusion features: it recovers loss, it does not create bandwidth or survive an outage. If a link is dropping packets because it is saturated, FEC will not help and may hurt; if it is dropping packets because it is genuinely lossy but has headroom, FEC is exactly right.

Best practice from Peplink’s SpeedFusion Whitepaper: when you have a capable router and bandwidth to spare, running WAN Smoothing and FEC together gives the best real-time performance, smoothing absorbs latency spikes by duplicating across links, FEC infills the packets that are still lost. The one documented exception is streaming video on the move (vehicles, vessels): there, WAN Smoothing alone tends to be more reliable, because the links are so variable in latency that the FEC math struggles. On a moving platform, lead with smoothing; on a fixed lossy link, lead with FEC.

Part Seven: Sub-Tunnels

The topic

Sub-tunnels are multiple parallel SpeedFusion tunnels running under one connection between the same pair of endpoints. Each sub-tunnel can carry its own traffic profile and enable its own protection features independently. This is the mechanism that lets you stop treating “the SpeedFusion link” as one undifferentiated pipe and start giving different kinds of traffic the exact treatment each needs, on the same router, over the same WANs.

How it works on Peplink

You define sub-tunnels within a SpeedFusion profile, and you steer traffic into them with outbound policy and path cost. A typical three-sub-tunnel design:

• Real-time sub-tunnel — DWB plus WAN Smoothing (Medium/High) plus FEC, with a low RTT threshold and a small jitter buffer. Carries voice and video.
• Bulk TCP sub-tunnel — DWB with ACK optimization and bufferbloat mitigation on. Carries file transfers and backups, where throughput matters more than loss recovery; smoothing and FEC are deliberately skipped.
• Control / fail-safe sub-tunnel — conservative thresholds, higher path cost, no smoothing, minimal FEC. The dependable baseline path.

Each sub-tunnel costs a small framing overhead, roughly 0–2% per additional sub-tunnel, counting only the framing, not the protection features each one carries. Critically, each sub-tunnel needs its own firewall ports opened (covered in Part Twenty); forgetting to extend the firewall rules as you add sub-tunnels is the single most common reason a second or third sub-tunnel flaps while the base tunnel stays up.

Why it matters

Sub-tunnels are how you apply expensive protection surgically. Rather than smoothing the entire connection at 100–400% overhead, you put only the voice traffic on a smoothed sub-tunnel and let everything else ride a plain bonded sub-tunnel at the 14–18% baseline. This is the difference between a design that wastes half the customer’s bandwidth and one that protects exactly what needs protecting. It is the central tool of intermediate (Level 2) SpeedFusion design.

Field note

Sub-tunnel sprawl is a real failure mode. More sub-tunnels means more state to manage and more ports to maintain. Most deployments end up needing two or three, not eight. Name them by role (Real-Time, Bulk, Control) so the design stays legible, and audit periodically to prune ones nobody is using.