Part Two: SpeedFusion, The Engine
The topic
SpeedFusion is the protocol that bonds multiple WAN connections into a single, resilient virtual link. The thirty-second version: most VPN tunnels fail one of two ways under stress. Either they pick a single path and ignore the rest, or they break outright when a path drops. SpeedFusion does neither. It distributes packets in real time across every active link, and it recovers from loss or link failure without dropping the user’s session. It is the engine behind every Peplink router, and every feature later in this paper is a layer on top of it.
The cleanest way to hold SpeedFusion in your head is as a layered stack, from the bottom up:
- Encrypted tunnel — an AES-256 baseline. Every SpeedFusion connection is encrypted.
- Sub-tunnels and Dynamic Weighted Bonding — the bonding and path-selection foundation. Always running.
- WAN Smoothing and FEC — optional loss and jitter protection layered on top.
- TCP enhancements and acceleration — optional application-layer tuning at the top.
You can think of the lower layers as always present and the upper layers as features you opt into when a specific problem justifies their cost.
 The six SpeedFusion sub-technologies (West Networks SpeedFusion Technology Catalog).
How it works on Peplink
SpeedFusion builds a tunnel between two endpoints, your site and another point: a data center, a cloud instance, another site, or one of Peplink’s hosted endpoints. Traffic inside that tunnel is broken into packets that can travel across all the member links at once, and the receiving end reassembles them in the correct order. Because the application’s session is bound to the stable tunnel and not to any one physical link, the loss of a link just means the surviving links carry the packets; the session never sees the failure.
This is the single most important mechanical fact about SpeedFusion, and it is the source of more field confusion than anything else: it requires two endpoints. There must be something on the far end terminating the tunnel and doing the reassembly. You cannot bond, smooth, or error-correct with only one device, because the magic happens between two cooperating ends. The far end can be another Peplink router, a FusionHub virtual appliance in the cloud, or a Peplink-hosted SpeedFusion Connect endpoint, but it has to exist and be configured as the tunnel partner. A single edge router by itself, with no tunnel partner, can only do plain outbound load-balancing and link failover. It cannot do true session-surviving bonding, and it cannot do WAN Smoothing or FEC, because those are tunnel behaviors.
A note on names: you will hear PepVPN and SpeedFusion VPN. PepVPN is the base secure tunnel, available on every Peplink product; it offers the benefits of IPsec plus Peplink’s reliability features. SpeedFusion is PepVPN with the bonding and protection features (bonding, smoothing, FEC, etc.) enabled. In current usage the terms are often used interchangeably, but the distinction is real: every device can build a tunnel; the SpeedFusion features layered on that tunnel are what differentiate the models and care plans.
A word on what is happening underneath, because it matters for security and sizing. SpeedFusion does not build one tunnel between sites; it builds a full mesh of WAN-to-WAN tunnels, local WANs × remote WANs of them. A site with six WANs (say 4× 5G + 2× Starlink) talking to a two-fiber hub forms twelve tunnels. Each WAN-to-WAN link is secured independently with 256-bit AES, keyed by a Diffie-Hellman exchange with perfect forward secrecy, and the keys are renegotiated at random intervals. Because every link carries its own keys and only a slice of the session’s packets, an attacker would have to break all of them at once to reconstruct anything, which is what makes SpeedFusion effectively immune to man-in-the-middle interception.
Why it matters
Once you internalize “SpeedFusion is a tunnel between two endpoints that splits and reassembles a session across many links,” every downstream behavior becomes predictable. Bonding is splitting one session across links. Hot failover is keeping the session pinned to one link but ready to move instantly. Smoothing is sending duplicate copies. FEC is sending parity. All four are just different things to do with packets inside the same two-endpoint tunnel. The features are not magic; they are policies on a pipe that has two ends.
Field note
The most common first question from a customer is “can my one router bond my connections?” The honest answer is “bond them to what?” Bonding needs a partner. If they have a second site or a cloud endpoint to terminate the tunnel, yes. If they have a single router and nowhere for the tunnel to land, they get load balancing and failover, which are valuable but are not bonding. Setting this expectation early prevents the most common disappointment in the field.
From the field — the mobile mammography unit: A unit serving rural communities had to move large medical images from places with no wired internet, and single cellular and high-latency satellite had failed at any price. The answer was SpeedFusion bonding five cellular links into one reliable connection, with a matching device at the data center as the second endpoint. No far end, no bonding, that two-endpoint requirement is the whole reason it worked.
Part Three: Dynamic Weighted Bonding, The Always-On Foundation
The topic
Dynamic Weighted Bonding (DWB, sometimes written DWBB for Dynamic Weighted Bandwidth Balancing) is the algorithm that distributes outbound packets across the active WANs in real time. The word that matters is dynamic. The weighting is not a static ratio you configure once; it reflects the measured throughput, latency, and loss of each link, continuously. A link that degrades gets less traffic automatically; a link that recovers gets more. This is the core of SpeedFusion’s bonding behavior, and it is always on. Every sub-tunnel inherits it unless you explicitly pin a flow to a single WAN.
How it works on Peplink
DWB measures each member link and steers packets accordingly, moment to moment. Because packets from one session may travel different links with different latencies, they can arrive out of order, so the receiving endpoint holds a reorder buffer and reassembles them correctly before handing the session up to the application. That buffering adds a small, predictable latency floor, the price of coherence.
DWB has real tuning knobs, and Level 2 deployments live in them:
- Congestion criteria — whether the algorithm reweights on loss, on latency, or on loss-plus-latency together. Loss-plus-latency suits volatile links; latency-only suits links that are jittery but clean; loss-only suits links with sporadic drop bursts.
- Bufferbloat mitigation — on or off. Turn it on for cellular and satellite links with deep queues.
- ACK optimization — helps high-loss, high-latency TCP workloads, but watch stateful firewalls in the path.
- RTT threshold (low/medium/high) — how aggressively the algorithm reweights paths. Low is best for interactive, latency-sensitive use.
- Jitter buffer — absorbs variation, but increases one-way latency, so use it sparingly for voice and video.
Why it matters
DWB is the reason Peplink bonding behaves well across genuinely mismatched links, a 5G modem, a Starlink dish, and a wired DIA circuit all at once, where a naive round-robin would choke on the slowest path. It is also the baseline cost of running SpeedFusion at all. Even with no protection features enabled, the encryption, sequence numbers, reorder buffers, and tunnel framing cost roughly 14–18% bandwidth overhead (West Networks lab-validated). That range is your floor: a plain SpeedFusion tunnel with nothing fancy turned on runs at roughly 82–86% of raw throughput. Every protection feature adds to that, and the overhead is additive.
Field note
When a customer reports “uneven throughput” or oscillation on a bonded link, DWB tuning is the first place to look, not a bug. Inspect the RTT threshold, the congestion criteria, the bufferbloat setting, and the per-WAN cut-off latency, and compare the per-WAN loss and latency graphs. Most “bonding is broken” tickets are really “bonding is correctly avoiding a link that is misbehaving,” which is the algorithm doing its job.
From the field — bonding mismatched links at a mine: A remote mining site bonded wildly different circuits, multiple Starlinks plus cellular. Dynamic Weighted Bonding is what made that coherent: it weighted each link by its measured throughput, latency, and loss moment to moment, so the healthy links carried more and a struggling one quietly carried less instead of dragging the whole bond down.