Feature Request: MPTCP

MPTCP is a new(ish) protocol that is being implemented in several locations.

It allows load balancing/failover in a new way - a single TCP connection can use different paths throughout the connection. This means failovers to backup connections would occur without interruption to the TCP connection, and bandwidth could be shared across multiple WAN connections in an amazing new way.

Apple is already using it for their iPhone to allow using your WiFi network for talking, and then seamlessly transitioning your phone call to the wireless network when you go out of range of WiFi.

I think it would be an amazing feature for VyOs, and would put VyOs ahead of the competition:


It’s already implemented in custom Linux Kernels, so it should be fairly easily integrated into VyOs.

I too am excited about the possibilities of MPTCP, however have you experimented with the protocol? The problem is both ends of the TCP connection must be MPTCP capable. So the best use cases at the moment are where you control both ends of the connection (think TCP VPN or squid parent proxy etc).

For general client traffic, you need to proxy the TCP connection in some way (there are some experiemental general TCP proxies around, and for HTTP specifically, squid could be used).

Apple can provide the benefits of MPTCP because it’s functional for the services they provide (Siri, geo lookup etc).

So it would be an exciting thing to have baked into VyOS and the best use case I can think of is a multipath TCP VPN (OpenVPN or whatever). But then you have the drawback of TCP-in-TCP that have been documented everywhere on the Internet.

Yes, our specific application would likely be a multipath TCP VPN. We’ve tested using other distributions that tend to be bulkier, but would like to make something work on more cost-effective hardware specs, and VyOS can do it, I think.

Hopefully the benefit of aggregating two or more WAN links will outweigh the overhead of TCP-in-TCP.

You might see http://bugzilla.vyos.net/show_bug.cgi?id=448 for an alternative. I am curious if that would work for you.