Part Eight: SpeedFusion Boost, The Single-Link Tool
The topic
SpeedFusion Boost is acceleration for an individual link, particularly the high-latency, high-loss paths like 5G and Starlink. It is the one part of the SpeedFusion family explicitly designed to help even when only one WAN is available, which makes it directly relevant to single-uplink sites where bonding is impossible.
How it works on Peplink
Boost applies path optimization and acceleration to a single link inside a SpeedFusion connection, improving effective throughput and resilience on lossy or high-latency circuits beyond what the raw link delivers. It costs roughly 10–15% overhead per link depending on link quality, but on a genuinely lossy path the acceleration usually more than pays for that cost. Boost requires a Boost-capable peer, another Peplink router or a FusionHub, on the far end; mixed-version pairs that do not both support Boost will silently fall back to base SpeedFusion, so version-match the endpoints.
Why it matters
Boost is the honest answer to “I only have one connection (Starlink, or a single 5G modem), what can Peplink do for me?” Bonding needs two links and smoothing needs path diversity, but Boost plus FEC genuinely improves a single lossy uplink. For a Starlink-only site, the standard recipe is SpeedFusion plus Boost plus FEC: Boost gives throughput on the high-latency path, and FEC handles the weather-related drops.
Field note
Boost is the piece that makes single-WAN SpeedFusion worth deploying at all. Tie this back to the single-WAN smoothing question: the right single-WAN design is not smoothing, it is Boost (for throughput) plus Adaptive FEC (for loss, ~6–20% overhead versus smoothing’s 100–400%), terminated on a FusionHub or hosted endpoint, with the standing recommendation that a second diverse link is the only thing that buys true uptime.
From the field — Heathgate Resources, gigabit from the outback: A fire took out a mine’s microwave link, so the site bonded multiple Starlinks to a Peplink router with a SpeedFusion tunnel back to a FusionHub in the corporate cloud, and reached about 1.3 Gbps down / 250 Mbps up for 250-plus workers. SpeedFusion Boost is what keeps the slower Starlinks from dragging the faster ones down on that high-latency bonded path.
Part Nine: TCP Enhancements
The topic
TCP Enhancements are application-layer tuning at the top of the SpeedFusion stack, aimed at making TCP behave well over long, lossy, or high-latency paths where vanilla TCP is sluggish. The two you tune here are TCP Optimization and TCP Ramp Up. The third job, accelerating latency-sensitive interactive flows so they feel local, is delivered by SpeedFusion Boost (Part Eight), which is the name we use for it.
TCP Optimization tunes window scaling, MSS clamping, and congestion control at the tunnel edge, for TCP-heavy traffic on long-fat pipes. TCP Ramp Up grows the initial congestion window faster so short flows reach full throughput sooner, for workloads made of many small connections like web and APIs, and it is especially useful on satellite (Starlink) and congested LTE where slow-start otherwise wastes the first seconds of every connection. For latency-sensitive interactive flows, RDP, VDI, remote file servers, reach for SpeedFusion Boost, Peplink’s acceleration technology. How Boost achieves its speedup is proprietary, so describe it to customers by its result (the session feels local and snappy), not by any assumed internal mechanism.
How it works on Peplink
These features ride the SpeedFusion tunnel and add a modest framing cost, roughly 5–10% bandwidth, but the real consideration is CPU: acceleration holds per-flow state and is CPU-medium-to-high, so plan for higher-end routers in Boost-heavy and TCP-heavy roles.
Why it matters
These features turn a technically-up but frustratingly-slow link into a usable one. The classic case is a remote-desktop user on a high-latency connection: SpeedFusion Boost makes the session feel local. Knowing which to reach for, Optimization for bulk TCP, Ramp Up for many small flows, and SpeedFusion Boost for interactive latency-sensitive traffic, is the difference between fixing the complaint and guessing.
Field note
Watch stateful firewalls and ACK optimization together; aggressive ACK handling can confuse a firewall in the path. And size the router for the CPU load, not just the bandwidth: a small router can saturate its CPU on Boost/acceleration long before it runs out of throughput.
From the field — TCP over Starlink: In a lab demo, plain TCP over a single Starlink underperformed badly because of the link’s latency and loss; with Peplink’s TCP optimization over SpeedFusion the same link delivered around 180 Mbps. On long, lossy paths vanilla TCP leaves most of the pipe unused, and the TCP enhancements (with Boost) are what reclaim it.
Part Ten: Overhead Math and Sizing
The topic
Every SpeedFusion feature is additive. You start with the SpeedFusion baseline and add the overhead of each feature you turn on, so a fully-protected real-time stack can cost more bandwidth than the data it carries. The point of knowing the numbers is to size a customer’s link honestly, so you do not promise 100 Mbps of usable throughput on a 100 Mbps circuit that is carrying a heavy protection stack.
The reference matrix
(Bandwidth figures are West Networks lab-validated; Boost, TCP, and sub-tunnel figures are working estimates pending lab confirmation. Overhead is additive, stack them and the percentages add.)
| Technology | Bandwidth overhead | CPU | Port | Use when |
|---|---|---|---|---|
| SpeedFusion baseline (with DWB) | 14–18% | Low | UDP 4500 | Always on. Encryption + bonding + framing. |
| Sub-tunnels | +0–2% per | Low | UDP 4500 (+ per-tunnel pairs) | Different policies on the same router |
| Forward Error Correction | 13.3% (Low) – 26.7% (High) | Medium | UDP 4500 | Loss recovery without retransmit |
| Adaptive FEC | 6–20% | Medium | UDP 4500 | Variable loss; spends only when needed |
| WAN Smoothing | +100% (≤2×) to +400% (Max) | Medium | UDP 4500 | Real-time, cannot tolerate any loss |
| SpeedFusion Boost | ~10–15% (est.) | Medium | UDP 4500 | Single-link sites; interactive acceleration |
| TCP Optimization / Ramp Up | ~5–10% (est.) | High | UDP 4500 | TCP-heavy workloads |
Stacked, the way it actually adds up
Because overhead is additive, you compute a stack by summing the baseline and each enabled feature:
- SpeedFusion only — about 14–18%. Encryption, bonding, and tunnel framing. The floor.
- SpeedFusion + Adaptive FEC — about 20–38% (14–18% + 6–20%). The everyday real-time recipe on lossy links.
- SpeedFusion + FEC (Low) — about 27–31% (14–18% + 13.3%).
- SpeedFusion + FEC (High) — about 41–45% (14–18% + 26.7%). Heavier loss recovery.
- SpeedFusion + WAN Smoothing (Normal) — about +114–118% (14–18% + 100%). Real-time, more than doubles the traffic.
- SpeedFusion + WAN Smoothing (Maximum) — +400% or more. The extreme; reserve for traffic that genuinely cannot lose a packet, on a dedicated sub-tunnel, on links with bandwidth to spare.
- SpeedFusion + FEC + Smoothing — add all three: e.g., 14–18% + 26.7% + 200% (Medium) ≈ +240–245%. Rarely justified; if you are here, make sure you can name why.
These are lab and working baselines. The mechanism underneath is a fixed 80 bytes of overhead per packet (versus roughly 58 for IPsec and 60–80 for WireGuard), so the percentage depends heavily on packet size: small packets pay proportionally more. On the industry IMIX traffic mix (4,084 bytes), Peplink measures about 960 bytes of SpeedFusion overhead. Always measure in the customer’s own environment before sizing.
The decision guide, what to turn on when
| Traffic | Recipe | Why |
|---|---|---|
| Voice / video calling | SF + sub-tunnel + WAN Smoothing | Zero tolerance for jitter; dedicated sub-tunnel; the bandwidth cost is worth it |
| Bulk file transfer | SF + TCP Enhancements | Throughput beats recovery; skip smoothing and FEC entirely |
| RDP / VDI / remote desktop | SF + SpeedFusion Boost + FEC | Latency-sensitive but loss-tolerant; Boost helps, FEC catches the rest |
| Starlink-only site | SF + Boost + FEC | Single lossy link; Boost gives throughput, FEC handles weather drops |
| Video surveillance / IoT | SF + sub-tunnel + FEC | Many small streams; FEC on a sub-tunnel is the right balance |
| Web browsing / general office | SF (default) | Do not over-engineer; the base bond is enough |
Why it matters
The rule of thumb that keeps deployments healthy: start with base SpeedFusion, and add a feature only when you can name the problem it solves. Every percent of overhead is bandwidth the customer paid for and is not using for their data. The matrix is not a menu to max out; it is a cost sheet to spend from carefully.