MPTCP – Multipath TCP

Transport layer 1 Comment

Intro

Multipath TCP is an extension of TCP that will soon be standardized by IETF. It is a succesful attempt to resolve major TCP shortcomings emerged from the change in the way we use our devices to communicate. There’s particularly the change in the way our new devices like iPhones and laptops are talking across network. All the devices like the networks are becoming multipath. Networks redundancy and devices multiple 3G and wireless connections made that possible.

Almost all today’s web applications are using TCP to communicate. This is due to TCP virtue of reliable packet delivery and ability to adapt to variable network throughput conditions. Multipath TCP is created so that it is backwards compatible with standard TCP. In that way it’s possible for today’s applications to use Multipath TCP without any changes. They think that they are using normal TCP.

MPTCP Protocol Stack from rfc6897

Basics

We know that TCP is single path. It means that there can be only one path between two devices that have TCP session open. That path is sealed as a communication session defined by source and destination IP address of communicating end devices. If some device wants to switch the communication from 3G to wireless as it happens on smartphones when they come in range of known WiFi connection, TCP session is disconnected and new one is created over WiFi. Using multiple paths/subsessions inside one TCP communication MPTCP will enable that new WiFi connection makes new subsession inside established MPTCP connection without braking TCP that’s already in place across 3G. Basically more different paths that are available will be represented by more subsessions inside one MPTCP connection. Device connected to 3G will expand the connection to WiFi and then will use algorithm to decide if it will use 3G and WiFi in the same time or it will stop using 3G and put all the traffic to cheaper and faster WiFi.

TCP single path property is TCP’s fundamental problem

In datacenter environment there is a tricky situation where two servers are talking to each other using TCP to communicate and that TCP session is created across random path between servers and switches in the datacenter. If there are more paths of course. If there are (and there are!) another two servers talking in the same time, it will possibly happen that this second TCP session will be established using partially the same path as the first TCP session. In that situation there will be a collision that will reduce the throughput for both sessions. There is actually no way to control this phenomenon in TCP world. As in our datacenter example the same thing works for every multipath environment so it it true for example for the Internet.

Answer is MPTCP!

Multipath TCP – MPTCP is better as TCP in that enables the use of multiple paths inside a single transport connection. It meets the goal to work well at any place where “normal” TCP would work.

Multipath TCP, as the name says, enables the creation of multiple paths within one MPTCP session and in that way achieves better performance and adaptation of sessions. Thers was probably a great effort to make MPTCP compatible with TCP so that there is no need for any change in networks, devices and apps. After all, without this compatibility there would be no deployment and furthermore no use of MPTCP. Nobody wants to change the whole Internet because of better protocol!

That is the main reason for the creation of multipath capability of TCP, performance improvement by distributing traffic load to more than one subflows across different paths. That of course additionaly requires that MPTCP always performs at least as well as standard TCP with one path. They are exaples when that goal was not meet but there are solutions in buffer size customizations andd implementation of algorithms that would mitigate reduced performance issues.

MPTCP works if both sides of the communication (user and server) have support for MPTCP. If only one side has MPTCP deployed that device will try to use MPTCP but it will only suceed to establish normal TCP session. It will always try MPTCP first and if there is no answer from other side it will use TCP.

Applications are not MPTCP aware; Apple IOS7 is first operating system in production that uses MPTCP and solely for Siri application that is now able to use WiFi and 3G simultaneously.

But how this works?

Multipath TCP is evolution of standard TCP that makes multipath data packet transport over one connection possible. Multipath TCP is made for next generation devices like iPhones and other smart devices that are multihomed (they use different Internet access options like WiFi and 3G).

To make this kind of communication over more different paths possible there is still need for data sequence number. From normal TCP you know that data sequence number is used to put the segments in order when they all arrive at the receiver. But now they can arrive to the receiver using more than one subflows inside one MPTCP connection. How will then be possible to put them in the order at the receiver. And more interesting than that, how will this whole MPTCP connection keep track of loosed packet accross the connection. One more thing, some IDS midleboxes will not allow the TCP subflow with gaps in the sequence space (from MPTCP arhitecture this subflow will be seen as normal TCP flow).

There should be a way to keep track of loss detection and retransmission of packets across every separate subflow. So the only answer to that question is to use sequence number for each subflow that will track loss and retransmission and separate data sequence number for reordering of packets at receiver side.

On this image below we are looking at standard TCP header from frc 793 that must stay as it is to keep backwards compatibility of MPTCP. The creators of MPTCP did play with some header parts and they decided to put data sequence number and data ACK inside TCP as new option. There was a second way of doing that by encoding data sequence number and data ACK inside payload (data). Fortunately they decidec to use TCP new options so that there will be no chance of deadlocks. (will explain in some other article). One more thing is that using TCP new options there is more chance that traversing different strange firewall midleboxes will be succesful. Middleboxes like firewall and others tend to remove some strange payloads and sometimes even TCP options if they don’t understand what they are.

MPTCP header format

What that means?

Here’s an example with two subflows inside one MPTCP connection. Data is send in three data frames of witch two are taking red subflow and one is taking green subflow. Data sequence numbers are 1,2,3 for whole MPTCP connection so that packets on receiver side can be ordered and connected into whole data. Subflow sequence numbers are 200,201 for red subflow and 300 for green subflow. In that way each subflow can have loss detection and retransmition of lossed frames.

MPTCP two flows

In for some reason one of the subflows (in our case green subflow) breaks down, the frame with DATA:2 will be redirected to other subflow in the way that it can be sent to receiver. His Subflow sequence number will be changed in order to go across red subflow and the data sequence number will stay the same (2) as this is the same frame.

MPTCP subflow goes down

All of this will happen without breaking the MPTCP connection so that device will practically not see anything going on, maybe only a little delay in loading content across that connection.

MPTCP data frame redirection to other subflow

 

Summary:

This article was written by me in the last few days as I got into learning how this new TCP technology works. I would like to post here all the materials I used to get to know MPTCP theory and way that it uses to function.

 

 

Related Posts:

One Response

  1. Shael_AT January 13, 2014

    As someone who is reading Routing TCP/IP Volume I and II, this just blew my mind.

    Reply
  2. Pingback: Multipath TCP January 13, 2014

Leave a Reply