A Multipath Transport Protocol for Future Internet

Our work aims to assess a multipath transport protocol named MPTCP (Multipath TCP), especially the various congestion control and coupling mechanisms considered for this protocol. Many authors propose to take advantage of the multiple paths that are often available for a data flow to improve its performance and its robustness to the varying transmission conditions. The different layers of the TCP/IP stack have been considered. At the application level, some authors suggest to handle many simultaneous TCP sockets and to shuffle the data upon them, like PSockets (Parallel Sockets). Other authors propose to open many end-to-end sub-connections in the transport layer transparently for the application, like cTCP (Concurrent TCP). At the network layer, some routing protocols may use multiple paths to route packets, like CMR (Concurrent Multipath Routing). And some algorithms have also been proposed at the Link layer, to split the data flow over several channels, like McMAC (Multiple channel MAC).

Multiple paths between two end-points may have different characteristics (i.e. capacity, latency, etc.), or diverse and varying traffic conditions. In consequence, packets using different paths may arrive out of sequence to the receiver. In this case, according to the classical cumulative acknowledgement mechanism of TCP, the data receiver sends back duplicate acknowledgements. With the TCP mechanism Fast Retransmit the data source may then misinterpret these duplicate acknowledgements as an indication of packet loss due to a congestion in the network, and then wrongly reduce its throughput. An efficient multipath protocol has then to be able to deal with these diversity of characteristics to optimize the throughput and to react nonetheless properly to any change.

Transport protocols can take advantage of feedback mechanisms, through the acknowledgements for example, to gather end-to-end up-to-date information about each path. This information can then be used to optimize dynamically the control of the traffic on the multiple available paths, for instance moving the traffic away from a congested path. An IETF working group, Multipath TCP (MPTCP), has started in 2009 to specify a multipath transport protocol. The aims are to improve the performance of a multi-path flow, i.e. to be at least as good as a single-path flow on the best route, without consuming on any path more capacity than a single-path flow. A last objective is to balance the congestion, moving away the traffic from congested paths. With MPTCP protocol, a congestion control is performed on each path at the subflow level, and coupling mechanisms can be introduced to satisfy the design objectives. Many coupling methods have been proposed and compared, especially “Fully Coupled”, “Linked Increases” and “RTT Compensator”.

To analyse MPTCP performance and the way it reacts to different network situations, we have implemented the protocol as defined in the current MPTCP drafts (using their release of July 2010) under the NS-3 network simulator. We have also implemented the different methods proposed to couple the congestion control mechanisms between the multiple subflows. These diverse coupling methods mainly differ in the increase rate of their congestion window after an acknowledgement and in their window decrease after a packet loss.

Spurious loss detections due to the variety of path characteristics and traffic conditions remain an obstacle to achieve the optimal performance. We suggest to enhance MPTCP by adding packet reordering algorithms to face this problem. Many such mechanisms have been proposed to optimize the performance of Standard TCP in case of large jitter, for example on wireless access networks. These proposals may be grouped in two families: state reconciliation and delayed response. With mechanisms from the first family, the TCP source first enters the Fast Retransmit state. Then, when it detects the spurious lost, it reacts by returning to the state preceding the Fast Retransmit. With mechanisms from the second family, the sender avoids spurious retransmissions by delaying the response to congestion. We implement two packet reordering algorithms, from the first family: DSACK (Duplicate Selective ACKnowledgments) and Eifel. We choose these two as representative of their family because they are specified in IETF Requests For Comments (RFC) and they are already implemented in many operating systems. To detect spurious retransmissions, DSACK (RFC 2883) uses the SACK fields in the TCP header to declare the packets received correctly. Eifel (RFC 4015) uses the Timestamp TCP fields to distinguish the initial packet sent and from its eventual retransmission. We have adapted these two algorithms to the case of multipath and we have included them in our MPTCP implementation in order to assess their behaviour on NS-3 simulations. We simulate a MPCTP connection with two available paths to transfer a 10 GB file between two hosts interconnected throug

This content is AI-processed based on open access ArXiv data.