I am sure you had nice time thinking around the discussion captured in last blog (/blogs/2013/08/16/networking-beyond-tcp/).

So we know the problem well and we understand that trying to change the basis of networking is not going to be acceptable in any ways. Several researchers have worked together on this issue and finally came up with the proposal of MPTCP – Multi Path TCP.

Let us go back to the basics of TCP, connection establishment process is called three-way handshake. Host A sends a packet with SYN flag to Host B which responds back with a packet containing SYN and ACK flags. Finally Host A sends a packet with ACK flag which marks the connection as established and ready for data transfer. So the basics remain the same and MPTCP utilizes the unused portion of TCP packets called the options field. In a MPTCP session Host A will add MP_CAPABLE option to the SYN packet. If the receiving Host B supports MPTCP then it will add the same MP_CAPABLE option to the SYN-ACK response packet. The final ACK from Host A will as well contain the MP_CAPABLE option establishing the multipath TCP session in between Host A and Host B. There are many other TCP extensions which uses the option field as well thus it is nothing new to the TCP world.

So far nothing different than Host A and B knowing they have formed MPTCP session. Now Host A recognizes another interface to connect to Host B and initiates new TCP connection with different source address and different port. It is a normal TCP connection but in MPTCP world it is called a sub-flow in between Host A and B. For MPTCP stack to recognize that this is a sub-flow of an existing MPTCP session, Host A will initiate the SYN packet with MP_JOIN option. This option also includes information on which MPTCP session it should join. So the MPTCP session will recognize this new connection as a sub-flow of existing session and add to it. But if this is so simple then an attacker would easily be able to forge TCP connection to join others MPTCP session. Researches have taken care of this issue by ensuring cryptographic key exchange in between the two Hosts while they exchange MPTCP options. Thus with the help of cryptographic validation it is ensured that the new connection belongs to same host and can be allowed to join existing MPTCP session.

Similarly multiple sub-flows can be created and joined in the MPTCP session and once the session has multiple sub-flows it totally depends on Host A and B to decide which flow should be used for data transfer at given point in time. Each TCP connection maintains its own sequence and acknowledgment space and ensures it reliably transfers the data. At MPTCP layer the session will have its own receive window which is spread across all the sub-flows. It also has its own sequence space to keep track of how the data received from multiple sub-flows fits into the overall session stream. Here is a quick representation of how the overall stack looks like with MPTCP:

Interestingly MPTCP offers lot more flexibility as the sub-flows are not dependent on each other. The sub-flows can join and exit the MPTCP session at any point in time without impacting the whole session. This is where it perfectly fits into the Mobile use cases where the devices disconnects and reconnects based on availability of the network as it is on move. The Application layer will not even notice the fact that sub-flows are joining and exiting at their own will. MPTCP session will ensure that the Application has connectivity and smooth data transfer rate in between the two hosts.

Great stuff and this is what we built into NetScaler stack for ensuring that we can work with Mobile clients efficiently and ensure better end user experience. Stay tuned for next blog with details around our implementation…