I'm not sure if MPTCP is great or if it's an over-engineering that stuffs brand new abstraction into the socket layer. See, previously when open a connection w

I'm not sure if MPTCP is great or if it's an over-engineering that stuffs brand new abstraction into the socket layer. See, previously when open a connection with an unbound socket, it would always bind it to the local IP that points at the default router. If you had multiple interfaces and you wanted a specific local IP, you'd bind to it explicitly before connecting. But it has always been that a connected socket is bound to exactly one IP. If you want to use two IPs for connecting out, you will have two sockets. With MPTCP the socket can now end up being bound to two or more local IPs. So effectively it changes the abstraction of the socket model to be more of a collection of (conventional) sockets. Doesn't it sound like something that could be done in the userspace? Sure, it does :) Though on the other hand, networking code in the kernel has access to a lot more information about the state of the network, so it can make better decisions and quicker. For example, if there's an interface with no default route going through it, the userspace solution may still try and use its IP to try and connect out. The userspace will also need to monitor the routing table for changes and re-try connecting out in response ... so MPTCP makes more sense if you think about it, but a userspace solution is much easier to implement and deploy.