Dynamic MTU: How we fixed a common cause of browsing problems

You might have had times when you were connected to VPN, and as you browsed, you simply could not access a site, without any obvious indication of what the issue may be. Turning off the VPN, however, fixed the problem, suggesting that VPN use was the culprit.

So what causes browsing problems like this? With our own apps, we found that a common issue had to do with maximum transmission unit (MTU), so we set out to fix it.

How maximum transmission unit affects your internet experience

MTU is the largest amount of data, measured in bytes, that can be transmitted in a single packet on a network. 

When you interact with a website or app, a data packet typically must pass through your home router, your internet service provider, an ExpressVPN server, plus various other switches, routers, and servers, before reaching its destination. A packet’s path to your favorite website could take it around the world, with a route that changes depending on the day. Along the way, each link in this chain has a maximum transmission unit—some larger, some smaller. If your data packet is too large for one of the links, the transmission will fail. 

Think of it as a driving route with varying road sizes. If the width of your car is greater than just one of the roads on your way, you won’t be able to complete the journey.

In this way, your browsing is constrained by the smallest link, the “path MTU,” and there are no signals in advance of what the path MTU of any given route may be before your data packet sets off. When you use a VPN, the VPN determines the packet size—making it the VPN provider’s role to navigate through links that can accommodate different sizes. 

In the past, the way we’ve approached MTU within our Lightway protocol has been to set a fixed packet size for transmissions, one that is large enough to be efficient—allowing for fast speeds—but not so large that it would routinely exceed an MTU in its path, leading to a transmission failure. 

This provided a balance between performance and compatibility, but it was far from ideal. Users would still occasionally hit upon a lower MTU, blocking them from their destination. If you were in a coffee shop with a Wi-Fi router configured with an abnormally low MTU, for instance, you wouldn’t be able to use the Wi-Fi at all while connected to the VPN. Meanwhile, some transmissions could be larger if we hadn’t restrained the size to account for MTU issues.

Developing dynamic MTU

To solve this problem, we’ve adopted an approach recommended as a proposed standard by the Internet Engineering Task Force (IETF), an organization that sets technical standards. Within our Lightway VPN protocol, we’ve built in the ability to detect the largest packet size that can traverse a given route before the packet is transmitted. 

As Lightway encapsulates your traffic and sends it out, it also sends test probes of varying sizes to find the path MTU. This process is called path MTU discovery. Think of it as a test drive for a road trip using a bigger and bigger car to find the point at which the car cannot pass a road on your route. 

So Lightway sends bigger and bigger packets until a packet stops getting through to the destination. Your data packet is then sized for optimal compatibility and performance with the path MTU. This might be achieved through packet fragmentation, where a data packet deemed too large is split up, allowing it to fit the path MTU.

Some VPN providers might opt to give users a choice of setting their MTU size within their apps (such as with a toggle). While that can certainly be useful, our dynamic MTU solution goes a step further by automating the process, taking out the guesswork, and allowing the data to adapt without requiring the user to do anything. 

Split testing with feature flags

We performed a split test (A/B test) for this method, meaning we deployed the solution to a randomized group of users, then compared the impact against a control group without it. 

Split tests provide scientific, measurable validation that a technique actually solves an issue. For this and other similar split tests, we rely on feature flags, which allow developers to turn a feature on and off without having to release it publicly.

In the case of our dynamic MTU split test, the instances of internet not working while VPN is working were cut down by half when compared against the control group. Our technique worked.

Using feature flags, we’re able to expand the dynamic MTU technique to users who were originally in the control group in a safe and controlled manner. Currently, it is being rolled out to Lightway on our apps for Android, iOS, Mac, Linux, and our Aircove router. Rollout for our Windows app and non-Aircove router software is to come.

Users just need to ensure they are using the Lightway protocol, which in most cases is chosen by the app by default. Nothing needs to be done if you use auto-update (and there’s no extra cost to you). All the code changes we made to Lightway to implement dynamic MTU are publicly visible in Github.

It’s another example of how we’ve improved the ExpressVPN user experience—in a way that remains largely invisible to you. Go behind the scenes and read about how we’ve added post-quantum protections, upgraded to DTLS 1.3, and introduced auto-updates for our desktop apps with security top of mind.