Hi! This is Steve from the SpeedFusion team. Firmware 8.3.0 has been released (Download RC5 here), and we’d like to talk about the changes made to the core of SpeedFusion.
Since Firmware 8.2.0, we introduced Dynamic Weighted Bonding (DWB). For more information on DWB, please refer to this post:
https://forum.peplink.com/t/621f17a014c6ea55f585614b/
Now in Firmware 8.3.0, the first change you’ll notice is that the default policy for every new SpeedFusion profile has been changed to Dynamic Weighted Bonding, which we believe performs better than the original Bonding algorithm.
So, what’s new in the core of SpeedFusion?
1) Better Packet Loss Handling
In Firmware 8.3.0, one significant update is the handling of packet loss. In previous firmware, packet loss within a bonded tunnel could cause quite a lot of jitter and delays, negatively impacting the bonding performance.
Imagine the following scenario: a setup that bonds 2x WANs and sends packets through the bonded tunnel. Because different WANs have different latencies, the packets may not arrive in the correct sequence:
┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
│01│ │02│ │06│ │07│ │08│ │10│
└──┘ └──┘ └──┘ └──┘ └──┘ └──┘
WAN 1 ◄──────────────────────────────────────────────────────────────
┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
│03│ │04│ │05│ │09│ │11│ │12│
└──┘ └──┘ └──┘ └──┘ └──┘ └──┘
WAN 2 ◄──────────────────────────────────────────────────────────────
In a normal situation, when packets arrive, they are queued and forwarded to the destination in the correct sequence, like this:
┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
│01│ │02│ │03│ │04│ │05│ │06│ │07│ │08│ │09│ │10│ │11│ │12│
└──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘
◄──────────────────────────────────────────────────────────────
However, if there is packet loss, for example if packet [05] is missing:
┌──┐ ┌──┐ ┌──┐ ┌──┐ Delay ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
│01│ │02│ │03│ │04│ 05 ◄─────────► │06│ │07│ │08│ │09│ │10│
└──┘ └──┘ └──┘ └──┘ Δt └──┘ └──┘ └──┘ └──┘ └──┘
◄──────────────────────────────────────────────────────────────
The packets will be delayed, and packet [06] will stay longer than expected and affecting the performance.
In firmware 8.3.0, we redesigned the algorithm to more aggressively detect packet loss. In the best case scenario, if 8.2.1 takes 150ms(Δt) to determine packet [05] is a real packet loss and forward [06] to the destination, firmware 8.3.0 can handle this in 10ms(Δt). This will greatly enhance TCP performance.
How good is it? Let’s see it in action.
The following test bonds 2x WANs (ISP A and ISP B), both with 100Mbps and 10ms latency, and about 0.05% packet loss.
=================
Firmware 8.2.1, using SF VPN Test, yielded a result slightly higher than 105Mbps.
=================
Firmware 8.3.0 resulted in 163Mbps, an improvement of 50% over 8.2.1.
2) Mitigate Bufferbloat feature has been changed to be less aggressive
In Firmware 8.2.0, we found that the Bufferbloat handling logic could accidentally introduce packet loss in the tunnel. This is definitely not good, and unfortunately there is no perfect solution yet. So, we have made it less aggressive for now. In Firmware 8.3.0, when the connection is congested, you may see a higher latency, but it should be more compatible and work better in more scenarios. While this handling is not ideal, we are still working on improvements which will be seen in future firmware releases.
What you can expect if you turn off Bufferbloat Handling (which can be done in the SpeedFusion profile settings) is an increase in latency, as shown in the following example, where it goes up to 2000ms+. This will make the whole tunnel unstable.
=========
Bufferbloat Handling turned OFF, tunnel with 2000ms+ latency when congested:
=========
In Firmware 8.2.1, turning on Bufferbloat Handling made the throughput more stable and kept latency at a very low level. However, this overly aggressive logic introduced packet loss that is not expected.
=========
In Firmware 8.3.0, with Bufferbloat Handling, latency is allowed to increase to a higher level, but still stays below 500ms in the test.
This feature is still evolving. In future firmware releases, we may expose more options in the settings page so that it can be more customizable. Please give it a try and let us know how it performs in your environment:
3) TCP Ramp Up
On the SpeedFusion settings page, just above WAN Smoothing, there is a new option called “TCP Ramp Up”. I’d like to show you when to use this option and what to expect if this is enabled.
When you run a throughput test, some of you may notice that the throughput increases slowly, taking more than 10 seconds to reach full capacity.
Just like in the following example, it takes 10 seconds to reach 100Mbps+:
There can be multiple root causes, some of them can be:
- Bonding a low latency WAN with a high latency WAN, which makes the overall latency much higher, becoming a so called long fat pipe. Due to TCP restrictions, it will take a long time to fully utilize the bandwidth.
- Packet loss, which make TCP throughput ramp up slowly to avoid congestion.
By enabling the option TCP Ramp Up, it will boost every new TCP sessions to achieve lowest possible latency across the WANs, making it to ramp up faster and achieve maximum throughput in a very shot time.
Using the same environment as the above example, which took 10 seconds to get 100Mbps+, now only takes 4 seconds:
Just note that you’ll need 2 WANs or more (aka Bonding) to get benefits from it, if you see slow ramping up problem like the above, just give TCP Ramp Up a try.
What’s next.
This is it. Please share your experience with us so that we can make SpeedFusion better. We are still working on a lot of new features and improvements for future firmware releases. I’ll keep sharing more technical details like this one when new things are out!