Going multipath without Multipath TCP
I worked with the MPTCP Linux implementation before it was upstreamed. One of the exciting things about it was that it was the default: IPPROTO_TCP would attempt an MPTCP handshake. This meant that any unmodified application that had used TCP could inherit the magic of connection bonding and bandwidth aggregation, when used with an MPTCP capable server. Browser downloads, SSH connections, iperf, you name it!<p>It seems that one of the concessions necessary to get MPTCP upstreamed was to make it opt-in. Even if the distribution enables MPTCP in its config, and if the sysctl parameter disabling it is enabled, the applications must STILL request it via IPPROTO_MPTCP. It was probably the correct choice, but to me it destroyed a major benefit of MPTCP. If it can&#x27;t (easily) be used to enable unmodified applications to reap its benefits, then why was it written as a standards-based, backward compatible extension to TCP? There were so many extra hurdles to overcome by adopting those constraints. Modern protocol development, especially at the &quot;transport&quot; layer (though usually based on UDP), is easiest done in userspace these days. This enables easier experimentation, iteration, and delivering updates to your users. See Chrome and SPDY&#x2F;QUIC. (Incidentally, I recall some discussion on &quot;multipath QUIC&quot;, wonder where that led to).<p>To bring this comment back to the article, I love it. It sidesteps the protocol development hurdles and just says &quot;if we&#x27;re going to require modified clients and servers anyway, let&#x27;s shove it into the application layer in a library&quot;. I&#x27;m sure approaches like this could handle all the same use cases:<p>- maximizing throughput of multiple interfaces, as the article does<p>- connection handover (by making a new connection over a new IP&#x2F;interface before breaking the old one)<p>- reducing latency by racing the same data across all interfaces<p>- using metered (e.g. LTE) connections as backup for poorly performing default connections<p>Of course, applications would need to be modified to use such a library, but that&#x27;s what the community seems to have decided is the way forward regardless :&#x2F;