===================
Manual bond tuning
===================

Much of the performance tuning can now be `done
automatically. <automatic-bond-tuning.html>`__

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 <reviewing-speed-test-results.html>`__ 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:

   a. 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

#. Carefully `set the download and upload speed of each
   leg <manual-leg-tuning.html>`__.
#. 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 <testing-leg-latency.html>`__.
#. Update the following bond settings:

   a. 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:

   a. 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.

      |image0|

      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 <../../spaces/technical-support.html>`__
   for assistance with this bond.


.. |image0| image:: /attachments/1639514/1933406.png
