Manual bond tuning¶
Much of the performance tuning can now be done automatically.
SD-WAN can bond a wide variety of Internet connections, from DSL and cable Internet to fixed wireless and mobile broadband. However, in some environments it can be difficult to achieve the expected throughput. For example, suppose a bond has a 50 Mbps cable connection and a 15 Mbps DSL connection. You would expect to see bonded speeds of 60 Mbps or more. However, if the cable leg has high jitter, a single TCP download may get only 30 Mbps—about half the expected throughput. To get the expected throughput from a bond, extra care needs to be taken when configuring challenging bonds such as this one.
Performance issues are typically seen when running a single TCP download or upload over the bond. The problem is related to the congestion control feature of TCP, which normally does a good job of seeking out the available bandwidth in a network but can limit transfer speeds when used in certain bonded environments. Performance problems are rarely encountered for UDP transfers or when multiple people are using the bonded connection at the same time.
Challenging environments¶
Environments where it is challenging to get the expected throughput from a bond include:
- When bonding different types of connections, such as DSL and fixed wireless. However, this does not apply if the only leg of a different type is set as failover. For example, in a bond with two DSL connections and a fixed wireless, if the fixed wireless connection is set as failover, then the DSLs are the only connections used together and performance is not usually a challenge.
- When bonding any connection with varying bandwidth or latency, such as some cable Internet connections and most wireless technologies.
- When bonding any leg on an over-provisioned network, since this reduces the available bandwidth and increases the latency and jitter of the connection.
- When bonding bursting connections, which provide higher bandwidth for the first 10-30 seconds of a transfer and then throttle the connection down to a slower speed. Legs like this must be set to the speed available after the burst has completed.
The speed testing features of SD-WAN can be used to investigate the bandwidth stability, delay, and jitter characteristics of a leg. See Reviewing speed test results for help on interpreting speed tests.
Tuning procedure¶
In most common bonding environments, SD-WAN can provide 90-95% of the ideal bonded bandwidth. In challenging environments, with careful tuning, it can achieve more than 85% of the ideal bandwidth. For example, bonding a 50 Mbps cable and 15 Mbps DSL connection, the bonded connection should be able to deliver at least 55 Mbps.
To tune a bond for optimum performance, follow these steps:
Set the bond configuration as follows:
- QoS profile: whichever profile you plan to use for this bond in production
- Packet distribution algorithm: Weighted round robin
- Flowlet delta: 0
- Reorder max hold: 30 ms
- Compression: disabled
- TCP proxy: disabled
- TCP proxy concurrency: 4
Run TCP download and upload tests with no rate limit and the bond as the target. If both the download and upload throughput is 90% or more of the ideal bonded bandwidth, you can stop—you have tuned the bond successfully. If the result is less than 90% of the ideal bonded bandwidth, or if you want to achieve more than 90%, continue with the following steps.
Using the results of the speed tests you ran in step (2), find the latency of each leg.
Update the following bond settings:
- Packet distribution algorithm: Considering only non-failover legs, if the bond has legs of different types or any leg has low stability or high jitter, set the packet distribution algorithm to IDMPQ. However, if the bond is assigned to an aggregator that hosts more than 100 legs, then leave the packet distribution algorithm as flowlet, due to a CPU load issue on the aggregator that will be resolved in a future release.
- Reorder max hold: Considering only non-failover legs, find the highest and lowest latencies of the legs. Set this field to (highest latency - lowest latency) / 2. For example, suppose a bond has three DSL connections and a failover mobile broadband connection. The DSL connections have latencies of 10 ms, 20 ms, 30 ms, and the failover mobile broadband connection has a latency of 40 ms. Since the failover leg is not considered, the highest and lowest latency is 30 ms and 10 ms. The reorder max hold field should be set to (30 - 10) / 2 = 10 ms.
Again, run TCP download and upload tests against the bond. If the result is 90% or more of the ideal bonded bandwidth, stop. Otherwise continue with the steps below.
Enable the TCP proxy on the bond.
To find the optimal TCP proxy concurrency setting, run a series of TCP download tests with concurrencies of 4, 8, 12, and 16, as follows:
Run a speed test with the necessary concurrency setting. For example, to run a test with concurrency 4, set up the test as in the screenshot below.
This concurrency setting is for the speed test, not for the TCP proxy concurrency setting in the bond configuration. The results of the concurrent speed tests will be used to set the value of the TCP concurrency setting later.
If the result of the test is greater than 90% of the ideal bonded bandwidth and the throughput chart is fairly stable, stop. Set the bond TCP proxy concurrency setting to the value used for the speed test and stop the procedure.
If the result of the test was less than 90%, repeat the test with the next concurrency value. For example, if the results were poor with concurrency 4, repeat the test with concurrency 8. Avoid using concurrency settings higher than 16—if you test with concurrency 16 and the test result is less than 90%, continue the procedure below.
If the throughput of a TCP download test with concurrency 16 is 85% or more of the ideal bonded bandwidth, then stop. We do not recommend concurrency values greater than 16. If it is less than 85%, consider contacting technical support for assistance with this bond.