I love the concept of WAN smoothing but it is a heavy price to pay if the options are double, triple or quadruple the bandwidth depending on the smoothing level. It would be awesome to have some sort of efficient option to choose where the smoothing kicks in as needed – focusing on WHERE it is needed and not smoothing WAN’s that are healthy.
For example, if certain WAN connections may be losing packets and others are more reliable, then perform WAN smoothing only on those connections. Yes, there would be a lag for it to kick in as there would be detection time to factor in, but that may not be terribly significant. Especially if it is determined that smoothing on individual WAN’s can stay on for long periods rather than fluctuating back and forth on to off.
Another option, perhaps, might be to pair up “naughty” WAN’s that are losing a lot of packets and hope that they could smooth each other out, leaving the healthy WAN’s without smoothing in order to maximize capacity.
Since I am not a network engineer I have no idea if the specific ideas here have any merit but consider this a vote to have some kind of more efficient option for smoothing.
This is a good idea in theory, but in practise it would require obscene levels of processing power to achieve it. Each Peplink at either end of a VPN would need to proactively monitor and test and react to network conditions in real time, then dynamically build and teardown routing logic to initiate and deactivate WAN smoothing on groups of WAN links.
Of course it is possible, but to achieve it the Peplink devices would likely need more processing power, more RAM, be bigger and more expensive and we’d soon get to the point where they would be unattractive commercially.
Instead, I would suggest you consider looking at the latest SF feature which is outbound policy for Speedfusion. This allows you to set up multiple tunnels between two end points and configure each of those tunnels differently. So you could have a tunnel with WAN smoothing enabled, and another one with lowest latency set. Then only send your most important traffic via the WAN smoothing tunnel (like VoIP).
That way the bandwidth overhead of WAN smoothing is only on specific traffic types and not all of your traffic.
The whole idea is to make it “smarter” in that it would adjust itself rather than require intervention. This idea could be extremely compatible with this new SF outbound policy feature because that is essentially what I am talking about except have it managed automatically.
In a way, statistics are already being generated for wan smoothing so I don’t see how it would take more processing power for that. If wan smoothing is taking place and packets are being filled in or whatever the term might be, then start counting how much of that is going on. If smoothing activity is idle, then turn it off after awhile for certain WAN’s. I am not talking about rapid changes to the smoothing settings… maybe no more than 5 minute changes or whatever would be practical.
Heck, currently I don’t know that there is any indication at all as far a how much smoothing is taking place so that also would be a nice feature so you could manually make these more informed decisions.
Yes we agree WAN Smoothing need to become smarter, but this require a more complex algorithm and we are still working on a solution to balance the complexity and performance gain (especially when this happens on low end device like Balance 20). In the mean time just like what @MartinLangmaid said, Outbound Policy for SpeedFusion actually is our first step to make WAN Smoothing more applicable in different scenario (now you can apply WAN Smoothing on particular packet type, while other traffics can bypassing WS), but absolutely we are not stopped here and are still enhancing WAN Smoothing in different ways.
