MPTCP is supported by more and more servers these days!

Note: if you don't see the two large graphs at the top, disable ad-blockers and/or try with another browser.

More and more apps (mostly server apps) have a dedicated option to enable MPTCP. Some server apps have even decided to enable MPTCP support by default, which makes sense: if MPTCP is not requested, TCP is used like before. Note that server apps written in Go usually have MPTCP enabled by default (if supported by the OS/kernel). See: https://www.mptcp.dev/apps.html

mptcp.io monitors servers supporting MPTCP.

> I dont think it’s well supported as a client yet

It is: by default, NetworkManager will configure MPTCP endpoints, so app can use multiple interfaces (if any). See: https://www.mptcp.dev/pm.html

> who knows if Android will ever

Sadly, it is difficult to talk to people in charge there. A few years ago, they were interested in MPTCP, but it was not available in the official Linux kernel. Now it is, and easily accessible (especially for small actors)... but Google has enough resources to find and use alternatives they fully control.

There are different ways to force an app to use MPTCP, where the most convenient method is 'mptcpize run <cmd>', see: https://www.mptcp.dev/setup.html#force-applications-to-use-m...

But the best is to let the app (and their users) controlling that, with a nice option. With Chrome/Firefox/..., we could enable MPTCP per domain for example.

Of course you can do that. There are different timeouts (MPTCP level, TCP (and SSH) keep alive, etc.) to prevent having dangling connections for a while, but they can be changed if needed.

Such middleboxes can also be seen in cellular networks. (And firewall in free access points / guest networks)

>Such middleboxes can also be seen in cellular networks.

Complain to your ISP if they mingle with a layer they are not supposed to mingle with.

>(And firewall in free access points / guest networks

I consider those as "corporate".

Some ISPs in Europe are using MPTCP for people being too far from the street cabinets. Typically, for people in the countryside, with < 50 Mbps. Thanks to a transparent proxy installed in the home gateway, and servers in the ISP's network, they can combine both the fixed and cellular networks, and use the fixed one in priority.

MPTCP can also be very interesting for mobility use-cases, even when one network is used at a time, e.g. switching from WiFi to cellular, or different cellular networks in the train, etc.

Note that MPQUIC is still being discussed at the IETF. At the last IETF meeting, more changes have been discussed. Unfortunately, that slows down its adoption. https://lwn.net/Articles/964377/

But both tries to achieve the same goal. Technically, you can have a very similar behaviour. MPTCP is implemented in the Linux kernel, while QUIC is on the userspace side.

Yes, that's correct. In the Linux kernel, it would not be possible to switch to MPTCP by default.

But apps can use it by default. For the server case, it really makes sense: https://www.mptcp.dev/faq.html#why--when-should-mptcp-be-ena...

GNU/Linux distributions could even switch MPTCP on by default (via eBPF).

I hope some apps will start using it :)

Good point, the last version (v0.60) is using the upstream kernel by default. I just added it in the list: https://www.mptcp.dev/apps.html#misc