Multipath TCP: an overview

They also have a 'cross-layer negotiation' design, allowing the decision of *which* minion is used to be made on a per-connection basis.

Their general concept of splitting the Transport layer up is (in my view) a very useful one. Even though the IETF passed on codifying it into the literature, it's a very useful pattern in designing protocols - layer an endpoint layer, a congestion layer, an isolation layer, and a semantic layer.

By using UDP as the endpoint layer, you can (potentially) avoid some of the problems MPTCP had to engage in heroics to deal with.

By using (say) a portless variant of DCCP on top of that as congestion control, you have something that could still be within the kernel (after all, there are various protocols implemented in the kernel that go on top of UDP or TCP) but because of the benefits of using UDP as the endpoint layer you don't have the horrific barriers to deployment DCCP proper ran aground on. Plus, this makes per-link congestion control feasible without breaking end-to-end reliability - which has been a significant problem due to the absolutely atrocious interaction of TCP, wireless LAN, and multiple layers of retransmission latency.

Layering the isolation layer here (rather than on top of the semantics) is genius. Aside from that it means you only need a design for datagrams, and not streams (so you can use DTLS regardless of the application-level semantics), it also means that the (intelligent in braindead ways) middleboxes only know information that they might have a valid reason to touch. Beyond that, they basically get told to push off.

Finally, you can build just about any semantics you like on top, by using the resulting building block of secure, point-to-point, CC-friendly unreliable datagram channels.