Having Multipath TCP inside the operating system allows all applications to automatically benefit from its features without forcing each application to reinvent the wheel. Operating system services help application developers by providing them with reusable services through standard APIs. In the case of Multipath TCP, at least on Linux, the standard API is the socket API.

MOSH only works with ssh, while Multipath TCP works with any unmodified application that runs on top of TCP. ssh is one of them of course.

SCTP is cleaner than Multipath TCP, but unfortunately there are on today's Internet many devices such as NATs that do not understand SCTP and simply block SCTP packets.

The main benefit of Multipath TCP when used in multihoming scenarios compared to BGP-based multihoming is that Multipath TCP capable hosts can use different paths simultaneously while BGP-based multihoming would provide one path for each client server pair.

With Multipath TCP, multihoming must be exposed to the server. For example, consider a small enterprise network connected to two different providers, A and B. With BGP-based multihoming, you assign address C to your server and advertise it through the two providers via BGP. BGP decides which path will be used and the ASPath metric used by BGP is far from being the most accurate metric to evaluate the quality of a path.

With Multipath TCP, you should ask a block of addresses from both A and B and assign one address from each provider you your server, say A.1 and B.1. Both addresses are advertised in the DNS. Address A.1 is always reachable via provider A and B.1 always reachable via provider B. When a TCP connection reaches the server, say over A.1, it will also advertise address B.1 using Multipath TCP and a second subflow will be established. Multipath TCP will then regulate the usage of the two paths in function of the amount of congestion on each path. If one path fails, Multipath TCP will perform failover automatically.

Multipath TCP traverses NAT and other types of middleboxes without problems.

Multipath TCP works in this use case and supports seamless handover. See http://inl.info.ucl.ac.be/publications/exploring-mobilewifi-handover-multipath-tcp for a detailed explanation. See https://github.com/mptcp-nexus/android for the MPTCP port on the google nexus

This works. The video used on the front page of the Multipath TCP website runs over ssh with 3G,WiFi and Ethernet.

http://www.youtube.com/watch?feature=player_embedded&v=VWN0ctPi5cw

Multipath TCP supports transparently IPv4 and IPv6. A Multipath TCP connection can start over IPv4 and then use IPv6 without the application being aware of the utilisation of IPv6. This could help the utilisation of IPv6 paths by IPv6 unaware TCP applications.

The current implementation in the Linux kernel only exposes the first address used in the connection to the application. If the addresses change, the application is not informed but the TCP connection remains alive. Exposing addresses to the application is an old mistake of the socket interface. The socket interface does not expose packet losses because TCP deals with them and provides a bytestream abstraction to the application. Multipath TCP does the same, it handles all changes in address transparently to the application.

The limit here is the CPU and on the sender and the receiver. Both servers used in the test reached 98% CPU load to achieve 52 Gbps. Note that 52 Gbps is the googput at the application and not the bandwidth used on the links (which is higher due to the various overheads)

SCTP is cleaner than Multipath TCP, but it suffers from two drawbacks that hinder its deployment in today's Internet : - many middleboxes only support IP, ICMP and TCP and discard SCTP packets (or do not perform NAT correctly) - applications need to be modified to support SCTP Multipath TCP is an evolution to TCP that works with unmodified applications and unmodified middleboxes.