Integrate Multipath TCP (MPTCP) for better speed and stability

[Victor239]

Issue description

Multipath TCP (AKA channel bonding) in my understanding works by a client on the user's device aggregating the internet connection from multiple sources (e.g. mobile Wi-Fi hotspot, ethernet connection, secondary Wi-Fi, etc) which is then forwarded to a VPN server which intelligently balances traffic across these multiple connections.

It is currently in use in several iOS apps as well as Speedify VPN is doing it commercially. MPTPC support is also being added into the Linux kernel, and the OpenMPTCPRouter project is working on it too. It would be great to see Mullvad support this also as I think it would result in a significant speed boost even compared to using no VPN at all.

[frafra]

Wouldn't that require to use OpenVPN? Wireguard works over UDP, so a UDP-over-TCP tunnel would be needed on top.

[frafra]

https://github.com/porech/engarde uses Wireguard to improve availability using multiple connections, but it uses way more bandwidth. As an alternative, an individual Wireguard connection should be open on top of every physical connection, and then bounded together somehow.

MullvadVPN supports Wireguard over TCP already: https://mullvad.net/en/blog/2021/11/1/introducing-wireguard-over-tcp-and-ipv6/. It should be rather easy to add support for Multipath TCP for such kind of connections.

[frafra]

I am not sure if Mullvad relies on https://github.com/mullvad/udp-over-tcp for supporting Wireguard connections over TCP; if that is the case, this issue could be relevant: mullvad/udp-over-tcp#30

[faern]

WireGuard over TCP is not good for performance. It's way slower than the regular WireGuard over UDP. Tunneling traffic inside a TCP connection is usually never a good idea. It is added to our app solely as an anti censorship and firewall circumvention technique. So implementing this with the speed argument and having it be backed by WireGuard over TCP sounds like a very bad idea. I'm pretty sure it would hurt performance a lot in total.

Not to mention the fact that you actually need multiple connections from the same device before multipath even makes sense. I'm pretty sure that users of mobile devices that have WiFi connections would be surprised and angry if our app starts blasting traffic on their carrier connection, eating up their precious bandwidth, which is probably both slower and more expensive than the WiFi.

[frafra]

Mullvad with Wireguard over TCP is slower than Mullvad with Wireguard over UDP, this is crystal clear, but this is not a good argument for not having a faster Mullvad when Wireguard over TCP is used, in my opinion. I am not convinced that it would be generally slower to use TCP-tunneled Wireguard over multiple connections compared to using a single connection with non-tunneled Wireguard.

No one proposed to have multipath enabled by default. An advance option would be nice, like in the case of Mullvad with Wireguard over TCP. That is a usability issue, not a blocker.

An alternative could be having different Wireguard (UDP by default) connection balanced together, or a multipath UDP VPN with Wireguard on top (https://www.notion.so/Multipath-TCP-UDP-155ee0b11c044d5d86f84b1b88b89cb0), but it would require some additional effort than using MPTCP.

The best solution would be having multipath UDP implemented in Wireguard. Someone looked into that last year: https://dl.ifip.org/db/conf/networking/networking2021/1570719654.pdf. I was not able to find any source code. Having that as an option in Mullvad would make Mullvad a competitor of other commercial products. I would be more than happy of funding such a feature.

I can understand if Mullvad decides to not add support for multipath because the company has different priorities, which is totally fine, especially since Mullvad provides such a great service.

[faern]

To better understand your use case and the use case you imagine others are having: Can you explain the setup that would benefit from this? To me it seems unlikely that people have more than one connection on their device (that they would actually benefit from using). Are you primarily thinking of mobile or desktop?

If you are on desktop, and you have both wifi and ethernet cable hooked up, at least it's my experience that they are always connecting to the same router, and the bandwidth is limited by your upstream connection, not how fast you can talk to the router. And on mobile, I explained above that I don't think most people would want a lot of their carrier bandwidth quota eaten up if they have access to a wifi?

[frafra]

I agree with you that this is not what most people want, usually.

Here are my personal use cases:

1. Better connection stability/no disconnections/no need to manually switch the network and reconnect
   1. Better connection stability on my laptop when attaching/detaching an Ethernet cable. This is common in an open space work environment or when working from home, and there is the need to move around for a meeting, or you plug the docking station to your laptop and the call or your connections fails.
   2. Relying on the 5G network when the wireless connection is not reliable. Work or campus areas where the wireless connectivity is bad.
   3. At airports, you can decide to use your own mobile network or the wifi one, which is usually for free, but time limited. When the connection ends, the OS is still connected to the wifi network, but no data is transferred.
2. Better performances
   1. Sometimes I would like to get something fast without having to switch network and interrupt my work. I live in an area where my 5G connection is ~850 Mbit/s down, and my landline connection is ~50 Mbit/s down. Sometimes it is worth to fetch data using the 5G connection, even if balancing between the two would be quicker, and you would use less of your mobile data quota.
3. A mix of both
   1. Trains with intermittent/flaky/slow mobile and wifi connection. Using both connection would improve both performances and stability.