Boost, WAN Optimization, and Performance Features

1. What Boost Adds

EdgeConnect has been described throughout this textbook as the SD-WAN platform that builds overlay tunnels, routes, steers applications across underlay circuits, and applies QoS. Boost is not a different product or a separate box — it is a software feature license you apply to unlock WAN optimization: TCP acceleration, data deduplication, and compression.

Picture the EdgeConnect appliance as a car that already ships with a capable engine (routing, path selection, segmentation). Boost is a performance package you license after the fact: the chassis does not change, but you switch on a higher-output mode that was always latent in the hardware. Without Boost, an EdgeConnect runs SD-WAN only — it routes, applies QoS, and performs path conditioning, but it does not terminate TCP sessions locally or maintain a deduplication cache.

Two characteristics define how Boost is consumed. First, it is a performance tier layered on the same hardware — you do not redesign topology to add it. Second, it is symmetric by requirement: optimization between two sites only happens when both EdgeConnect appliances on that path are Boost-enabled. A branch with Boost talking to a data center without it gets no WAN optimization on that flow — just standard SD-WAN path selection and QoS.

Figure 6.1: EdgeConnect with and without the Boost license

Allocating Boost Bandwidth Across the Fabric

Boost is not licensed per appliance as an on/off switch. It is licensed as a pool of WAN optimization throughput (Mbps or Gbps) that you draw from and allocate across your fabric in Aruba Orchestrator. You buy, say, a 300 Mbps pool, then assign slices to individual appliances based on how much optimized traffic each site needs.

Two allocation rules routinely trip up new administrators:

1. The optimized rate between two sites is limited by the smaller of the two allocations. If DC1 has 300 Mbps and Branch A has 20 Mbps, the optimized session runs WAN optimization up to 20 Mbps — the branch is the bottleneck. Boost capacity behaves like the narrowest pipe in a series.
2. Allocation is dynamic and software-defined. Because Boost is a license pool managed in Orchestrator, you can reallocate capacity between sites without touching hardware.

Within a single appliance, the allocated capacity is shared by all flows matching Boost-enabled policies. If DC1 has 300 Mbps of Boost but 400 Mbps of eligible replication traffic, Boost optimizes up to 300 Mbps and the remainder passes through unoptimized (still routed and protected by SD-WAN).

Figure 6.2: Boost pool allocation across a fabric

Use Cases for Long-Haul and High-Latency Links

Boost earns its keep on TCP traffic limited by latency or protocol inefficiency rather than by raw bandwidth or loss. A single TCP stream's maximum throughput is roughly its window size divided by RTT. On a "long fat" link — high bandwidth, high latency, such as a 120 ms intercontinental circuit — a default TCP stack cannot grow its window fast enough to fill the pipe. You can have a 200 Mbps link with 1% loss and still see a single backup stream plateau at a few Mbps. Adding bandwidth does nothing; the limiter is RTT and conservative window growth.

• Intercontinental and satellite links where RTT runs 80–200+ ms and individual TCP flows chronically underutilize capacity.
• Backup and disaster-recovery replication (NetApp SnapMirror, Dell EMC SRDF, Veeam, vSphere replication) that runs continuously, carries repetitive data, and must meet strict RPO/RTO.
• Bulk data movement — media assets, CAD files, large datasets, initial cloud-seeding migrations.

2. Optimization Techniques

Every Boost technique is, at its core, one of two tricks: send fewer bytes, or make the WAN look less lossy and less latent. The first is served by deduplication and compression; the second by TCP and protocol acceleration. EdgeConnect intercepts eligible flows at each end, optimizes them, carries the result across a private optimized transport inside the overlay, and reconstructs the original flow on the far side — transparently to the end hosts.

TCP Acceleration and Protocol Optimization

TCP acceleration is the headline latency-fighting feature. The mechanism is a TCP proxy (split-TCP / local termination). Instead of one end-to-end TCP session stretched across the WAN, there are three segments:

1. The client's TCP session terminates locally on the branch EdgeConnect.
2. A separate, WAN-tuned optimized transport runs between the two EdgeConnects.
3. The server's TCP session terminates locally on the data-center EdgeConnect.

Each host believes it has a normal, direct TCP conversation with the remote host. In reality each talks to a nearby proxy, and the long-haul middle leg is a high-performance transport tuned for the link's bandwidth and RTT. The specific tricks: local acknowledgments (ACK spoofing) so the client grows its window quickly; aggressive window scaling matched to the bandwidth-delay product; and WAN-tuned congestion control and loss recovery handled locally so endpoints rarely see drops.

On top of TCP, Boost adds protocol acceleration for chatty protocols whose problem is the number of round-trips: CIFS/SMB read-ahead, write-behind, and metadata optimization; and MAPI/Exchange, NFS, and HTTP request bundling and pipelining. Removing even a few round-trips per file open over a 100 ms link can turn a multi-second wait into a near-instant one.

Figure 6.3: Split-TCP proxy across the WAN

The middle leg also benefits from EdgeConnect's path-conditioning features: Forward Error Correction (FEC) sends redundant parity so lost packets are reconstructed without retransmission (keeping TCP from misreading loss as congestion), and packet-order correction (POC) re-sequences out-of-order packets in a small jitter buffer so TCP stays calm.

Network Memory Deduplication

The most distinctive Boost capability is Network Memory, Silver Peak's byte-level deduplication technology and the direct descendant of the dedup engine in the legacy NX and VX appliances. As traffic flows through, EdgeConnect breaks it into small chunks and fingerprints (hashes) each one. Both appliances maintain a synchronized dictionary. When a chunk's fingerprint already exists, EdgeConnect transmits a tiny reference token instead of the full chunk, and the far end reconstructs the data from its own dictionary. Endpoints receive byte-identical content with no idea most of it never crossed the WAN.

1. Byte-level, not file/block-level. It still finds repeated patterns when content is shifted, repackaged, or embedded across file types — the same logo in a PDF, PowerPoint, and email is recognized each time.
2. Cross-flow and cross-application. The dictionary is shared across all connections and protocols. The first open of a 50 MB presentation sends ~50 MB; later opens may send only a few hundred KB of differences.
3. Bidirectional and symmetric. Both ends keep caches, so dedup works branch-to-DC, DC-to-branch, and branch-to-branch.

On repetitive workloads, Network Memory commonly yields 5× to 20× effective (logical) throughput without any change to the physical link.

Figure 6.4: Network Memory deduplication

Compression and Payload Reduction

After deduplication removes repeated content, the remaining unique data is compressed with an LZ-style algorithm before crossing the WAN. The ordering is deliberate: deduplicate first, then compress. Compression is highly effective on text-heavy and structured data (source code, logs, XML, JSON, uncompressed documents, database traffic) but offers little benefit on already-compressed data (JPEG, MP4, ZIP) whose redundancy was already squeezed out at the source.

One caveat threads through all techniques: encryption. Dedup, compression, and protocol acceleration all need to see the payload, so end-to-end-encrypted traffic (HTTPS to SaaS, SMB3 with encryption) is opaque and those gains largely disappear. TCP acceleration, FEC, and packet-order correction can still help because they operate on the transport and packet level, not the payload.

3. Measuring the Benefit

Optimization features are only worth their license cost and CPU/disk overhead if they move the metrics the business cares about.

Reduction in Bandwidth and Latency

Bandwidth reduction comes from deduplication and compression; the headline metric is the dedup hit ratio — the ratio of pre- to post-optimization bytes on the wire. A 5:1 ratio means the WAN carries one-fifth the bytes the applications generated. A low ratio is itself a diagnostic: usually encrypted or unique traffic. Latency reduction comes from TCP and protocol acceleration; the right metric is time — file-open, transaction, or backup-job duration. A useful baseline: a long-lived flow consistently below ~30–40% of bandwidth at RTT above 50–70 ms (despite bonding and low loss) is latency-bound, and Boost likely helps substantially.

Application Acceleration Examples

• Branch SMB/CIFS to a central DC. Over 80 ms RTT, opening a large file takes 10–20s due to serial round-trips. After Network Memory + TCP/protocol acceleration, the first open is faster (round-trips collapsed) and repeat opens are near-instant from the local dictionary; effective file throughput rises 5–10×.
• Database replication over internet VPN. With 2–3% loss and 120 ms RTT, native TCP stalls at a few Mbps on a 100 Mbps link. With FEC + TCP acceleration + POC, loss is masked, spurious retransmits vanish, and throughput climbs to ~40–60 Mbps, protecting RPO/RTO.
• Cloud-hosted private apps from branches. With an EdgeConnect in branch and cloud VPC, dedup and protocol acceleration speed repetitive access while FEC/POC stabilize variable routes — the app feels on-premises.

When Optimization Is Unnecessary

The most important practical lesson: Boost is not always the answer. Standard EdgeConnect SD-WAN (business-intent path control, tunnel bonding, QoS, path conditioning) is sufficient or preferable when:

• Real-time voice/video. VoIP, WebRTC, Zoom/Teams, softphones, most VDI are UDP-based or already optimized; they want path conditioning, SLA steering, and QoS — not TCP proxying or dedup. (Boost is primarily a TCP technology.)
• Modern web/SaaS over HTTPS. M365, Salesforce, etc. are end-to-end encrypted and built to tolerate latency; direct internet breakout, local DNS, and QoS deliver more value — and often there is no second EdgeConnect to optimize against.
• Low-latency, near-line-rate links. Under ~40–50 ms with transfers already near throughput, there is little latency to hide.
• Already-compressed or CDN-cached data. JPEG/MP4/ZIP and CDN-served content offer minimal dedup/compression headroom.
• Cheap, plentiful bandwidth. Sometimes adding capacity plus tunnel bonding is simpler and cheaper than tuning Boost.

A second caution for migrations: do not double-optimize. Running Boost and a legacy NX/VX appliance in series on the same flows adds overhead and can break protocol semantics; phase out the standalone WAN-op boxes as you activate Boost.

Figure 6.5: Decision flow for using Boost versus standard SD-WAN