One other point to make about MPTCP: it has a congestion controller that takes pains to be fair with respect to regular TCP. It's a subtle problem... MPTCP sen

One other point to make about MPTCP: it has a congestion controller that takes pains to be fair with respect to regular TCP. It's a subtle problem... MPTCP sender -> [link1 | link2] -> shared link -> MPTCP receiver There might be a TCP flow using the shared link, in which case fairness means that the MPTCP sender should only send the same total traffic as would a single TCP flow. Or there might be a TCP flow using link1, and a second TCP flow using link2, and the shared link might be uncongested, in which case MPTCP could reasonably behave like two TCP flows. Or maybe there's a single path TCP flow using (link1 -> shared), or one using (link1 -> link2), or ... The MPTCP congestion controller was designed so that in all of these cases it's no greedier than if it were a single TCP flow. And it has to do this without knowing the network topology, nor what other flows are using the network. Reference: 2011 paper, https://www.usenix.org/conference/nsdi11/design-implementation-and-evaluation-congestion-control-multipath-tcp https://www.usenix.org/conference/nsdi11/design-implementati...