Multipath TCP: an overview

While complexity generally should be pushed to the end-stations and kept out of the network, as much as possible, that does not mean *all* complexity should be kept out of the network. There are certain basic functions that *should* be kept in the network, along with whatever complexity is required to support those functions.

E.g. the original designers of TCPIP believed it was very important for the network to abstract away differences in MTUs. They argued that otherwise it would be difficult for end-stations to reliably work-around differences in MTU, so that it would become difficult for the network to make use of larger MTUs. This would block the use of techniques such encapsulation, extra-addressing, etc., by end-stations to solve problems such as mobility, etc. For this reason they made TCPIP support fragmentation at the network level.

Sadly, later implementors and stewards of IP concluded differently. They moved to deprecate fragmentation from IPv4, and excluded it completely from IPv6. Instead, it was left to the end-stations to negotiate the correct MTU. Unfortunately however the original designers of IP have been proven correct. End-station MTU discovery has been proven to be fragile, and often does not work, due to stupid intermediate nodes blocking the required signalling (which is out of band). At the best of times it probably adds more latency than network level fragmentation.

As a result, the Internet is crippled with a 1500 MTU. :( The success of IPv6 would likely set this in stone.

See my blog: http://pjakma.wordpress.com/2011/06/28/cerf-and-kahn-on-w...