SD-WAN Link Aggregation Calculator

If you’ve ever been frustrated with your internet connection because it takes too long to download big files even though your internet service provider advertises blazing-fast speeds, you’re familiar with this issue. Raw bandwidth isn’t the same as usable throughput. When you take a speed test, you may think that’s the amount of capacity you have to use. The truth include more variables.

How does traffic flow through several different links? What impact do latency skew, packet loss and tunnel overhead has on advertised speed? Effective network planning starts with understanding the gap between what you pay for and what you get.

Why Your Internet Speed Is Slower Than You Think

The vast majority of folks will think that doubling the number of connection is just going to double their throughput. The calculator shows how intuitive fallacy leads them astray here. It factors in tunnel overhead, which subtracts some fraction of your bandwidth from whatever you’re using to protect and encapsulate traffic. Fail to consider this and you risk making capacity plans that are more hopeful then intended. “Sure I can do video chat!” But now those encrypted headers is hogging half your bandwidth.

It also factors in QoS reserves, so that bulk downloads don’t crowd out control or voice traffic. That’s especially valuable when a big update starts syncing.

Bonding modes also matter a lot in terms of their single-flow performance. While per-flow load balancing is good for general office browsing by spreading various users/applications over your links, it doesn’t accelerates a single large download. Packet striping can split a single flow, but it requires similar latency on your links. Otherwise, some packets will arrives before others and get reordered, reducing TCP throughput. As the reference table shows, each mode trades raw speed against some combination of stability/reliability. Rather than simply seeking out the biggest number, you should of select a mode based off what your actual applications require.

Another negative impact on performance comes from latency skew. Take, for example, combining a fast fiber link with a slower cellular back-up; you’ve now combined connections running at vastly different speeds. Your jitter, the delay between these two paths. Gets in the way of virtual desktop session (they’ll be laggy) and disrupts VoIP calls.

These penalties factor into the calculator’s SLA score, which is important because this number indicates if the connection is good enough to meet your needs. Having a large aggregate speed number doesn’t help if the underlying quality isn’t there. Sure, you may have lots of capacity, but if packets starts dropping intermittently, or arriving out of order, the application won’t know what to do with them.

But you shouldn’t ignore failover capacity until it’s needed. Active-backup configurations maintains an unused backup circuit in case of failure. That’s reliable because retail point-of-sale terminals are mission-critical. However, this configuration wastes money on unused bandwidth. A bonded setup uses all links simultaneously for maximum efficiency, but the complexity of failover logic become harder with one path degrading.

Is staying connected during an outage your top priority? Or do you want maximum throughput? It depends. This isn’t a free solution; it is just a set of tradeoffs that align with your budget and level of risk tolerance.

SD-WAN planning is about managing expectations, not going for top speed. Speed tests can be misleading because they don’t show your actual usable throughput. Managing it means considering flow behavior, loss, and latency. By matching your real application needs to your hardware capabilities, you make the network less mysterious and more predictable. The frustrating bottleneck becomes a reliable utility.