Peplink's VPN protocol, SpeedFusion, enables Peplink devices to connect seamlessly to each other no matter their location or connectivity method. Peplink is able to understand link status in realtime by looking at metrics such as latency and packet loss to deliver reliable and robust VPN connections over different media (cellular, satellite, etc.). While we tell most people that things "just work," there is quite a bit of additional data that one can use to fine tune a SpeedFusion VPN connection. 

In this article we will show you how to see some of this data and how to interpret it. Most importantly, you will see how SpeedFusion adjusts traffic flow to account for individual link characteristics. 

The Test Environment

This environment consists of a FusionHub instance in AWS and a BR2 Pro (5GK radio). On either side we're using encoder/streaming software to generate the stream. 

FusionHub has a static WAN IP address with port forwarding for the STP stream to a device connected to the BR2 Pro. A SpeedFusion tunnel has been established via FusionHub and the BR2 Pro using InControl2.

The encoder in the studio is running vMix 28 and connected to the internet via a 1Gbps fiber connection. 

On the far end, the BR2 Pro hosts a laptop also running vMix 28 and is connected using cellular radios, each using a T-Mobile SIM card.

On each end we were running vMix as both a listener and caller. You'll see further on in this article where we set the stream up as one-way and then two-way to demonstrate how SpeedFusion handles the traffic.

Where to Find the Data

To view realtime data on-device for the SpeedFusion tunnel between FusionHub and the BR2 Pro, head to the local device interface of the BR2 Pro or FusionHub (we are using the BR2 Pro here), head to Status > SpeedFusion VPN and then click the graph icon at the top right of the tunnel data window:

Interpreting our Test Data

Initially, we started the stream from the FusionHub side down to the BR2 Pro. This is the easiest part as cellular networks are tuned for sending data down to a cellular device, not having the cellular device sending it back.

The stream was started at 2Mbps from FusionHub to the BR2 Pro. You'll notice that SpeedFusion determined to use Cellular 1 exclusively for that traffic. 

After a few minutes, we increased the stream from 2Mbps to 10Mbps. You'll notice in the graphs that a few interesting things happened:

• Usage quickly spiked on Cellular 1, but so did latency.
• Latency spiked to nearly 2000ms!
• Packet loss was seen on Cellular 1 at the same time
• SpeedFusion shifted traffic almost entirely to Cellular 2 where no packet loss or major latency increases were seen

This is the power of SpeedFusion! There were no settings changes or human interaction here other than increasing the bitrate of the stream. 

Next, we told the device connected to the BR2 Pro to return the same stream at the same bitrate (10Mbps) back to the device sending it through FusionHub. This means that the BR2 Pro would need to both receive the stream from FusionHub as well as send it back, using the same two cellular connections it's already using to download the stream. When we did this, SpeedFusion made a few additional changes:

• SpeedFusion immediately started to return the stream via Cellular 2, causing a small latency spike (approximately 500ms). 
• A small amount of packet loss was seen on Cellular 2
• SpeedFusion shifted about half of the uplink traffic and a small amount of downlink traffic to Cellular 1
• At this point, you'll notice that SpeedFusion also started using Forward Error Correction as duplicated packets were detected and discarded. 

Here's what all of this looks like:

We hope this helps you understand the basic operation of SpeedFusion in practice and enables you to make adjustments to your tunnels using these graphs on your Peplink devices. 

Llama Networks can host and support your FusionHub environment! Reach out to sales[at]llamanetworks[dot]com if you need support with your Peplink environment.