Multipath TCP

2013-09-24T05:32:55Z

Syscomet: MPTCP option length is not fixed at 30; it's Kind 30, variable length

'''Multipath TCP''' (MPTCP) is an ongoing effort of the [[IETF]]'s [http://datatracker.ietf.org/wg/mptcp/ Multipath TCP working group], that aims at allowing a [[Transmission Control Protocol|TCP]] connection to use multiple paths to maximize resource usage and increase redundancy.

In January 2013, the IETF published the Multipath specification as an Experimental standard in RFC 6824.

==Benefits==
The redundancy offered by Multipath TCP enables statistical multiplexing of resources, and thus increases [[Transmission Control Protocol|TCP]] throughput to the sum of all available channels instead of using a single one as required by plain [[Transmission Control Protocol|TCP]]. Multipath TCP is backwards compatible with plain TCP.

Multipath TCP is particularly useful in the context of wireless networks <ref>[http://portal.acm.org/citation.cfm?id=1794199 TCP with feed-forward source coding for wireless downlink networks]</ref> - using both [[Wi-Fi]] and a [[mobile network]] is a typical [[use case]]: links may be added or dropped as the user moves in or out of coverage, with no perceptible discontinuity. The problem of interprotocol [[handover]] is thus solved by abstraction in the [[transport layer]], which removes the requirement for awareness at the network level, therefore keeping the functionality outside of the network operator's control - in accordance to the Internet's [[end-to-end principle]].

Multipath TCP also brings performance benefits in [[data center|datacenter]] environments.<ref name=":1">{{Cite journal | last1=Raiciu |last2=Barre |last3=Pluntke |last4=Greenhalgh |last5=Wischik |last6=Handley | title=Improving datacenter performance and robustness with multipath TCP | journal=Sigcomm | year=2011 | url=http://inl.info.ucl.ac.be/publications/improving-datacenter-performance-and-robustness-multipath-tcp | postscript= }}</ref> In contrast to [[Ethernet]] channel bonding using [[802.3ad]] link aggregation, Multipath TCP can balance a single TCP connection across multiple interfaces.<ref>{{cite web|url=http://multipath-tcp.org/pmwiki.php?n=Main.50Gbps
|accessdate=2013-09-20
|title=The fastest TCP connection with Multipath TCP
|author=C. Paasch, G. Detal, S. Barré, F. Duchêne, O. Bonaventure
}}</ref>

==User interface==
Multipath TCP presents the same user interface as TCP. It modifies TCP so that it presents a standard TCP interface to applications, while in fact spreading data across several subflows.<ref name="linux-kernel-multipath-tcp-project">{{cite web|url=http://multipath-tcp.org/
|accessdate=2013-09-21
|title=The Linux kernel MultiPath TCP project
}}
</ref>

==Implementation==
In July 2013, the MPTCP working group reported four independent implementations of Multipath TCP,<ref>{{cite web|url=http://datatracker.ietf.org/doc/draft-eardley-mptcp-implementations-survey/?include_text=1
|accessdate=2013-09-20
|title=Survey of MPTCP Implementations (Internet-Draft, 2013)
}}</ref> including the reference implementation<ref name="linux-kernel-multipath-tcp-project"/> in the Linux kernel.<ref>{{Cite journal |last1=Barre |last2=Paasch |last3=Bonaventure | title=MultiPath TCP: From Theory to Practice | journal=IFIP Networking | year=2011 | url=http://inl.info.ucl.ac.be/publications/multipath-tcp-theory-practice | postscript= }}</ref><ref>{{Cite journal |last1=Raiciu |last2=Paasch |last3=Barre |last4=Ford | last5= Honda |last6=Duchene |last7=Bonaventure | last8=Handley| title=How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP | journal=USENIX NSDI | year=2012 | url=https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp | postscript= }}</ref>

The currently available [[implementation]]s are:
* [[Linux kernel|Linux Kernel]] (reference implementation) from Université Catholique de Louvain<ref name="linux-kernel-multipath-tcp-project" />
* [[FreeBSD]] (IPv4 only) from Swinburne University of Technology<ref>{{cite web|url=http://lists.freebsd.org/pipermail/freebsd-net/2013-March/034882.html
|accessdate=2013-09-23
|title=Multipath TCP for FreeBSD v0.1}}</ref>
* [[Citrix Systems|Citrix]] Netscaler<ref name="citrix-netscaler">{{cite web|url=http://blogs.citrix.com/2013/05/28/maximize-mobile-user-experience-with-netscaler-multipath-tcp/
|accessdate=2013-09-20
|title=Maximize mobile user experience with NetScaler Multipath TCP
|author=John Gudmundson
|publisher=Citrix
|date=2013-05-28
}}</ref>
* [[Apple Inc.|Apple]] [[iOS7]], released on September 18, 2013 is the first large scale commercial deployment of Multipath TCP<ref>{{cite web|url=http://perso.uclouvain.be/olivier.bonaventure/blog/html/2013/09/18/mptcp.html
|accessdate=2013-09-20
|title=Apple seems to also believe in Multipath TCP
}}</ref>

==TCP segment structure==

Multipath TCP segment structure is described in detail in RFC 6824.

Data structures used by Multipath TCP are located in the TCP Options field, in a variable-length option; the option's registered TCP Option Kind is 30, as reserved by IANA<ref>{{cite web|url=http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1
|accessdate=2013-09-24
|title=IANA Protocol Registry TCP Option Kind Numbers
}}</ref>.

The Multipath TCP option has the Kind (30), length (variable) and the remainder of the content begins with a 4-bit subtype field, for which [[Internet Assigned Numbers Authority|IANA]] has created and will maintain a sub-registry entitled "MPTCP Option Subtypes" under the "Transmission Control Protocol (TCP) Parameters" registry. Those subtype fields are defined as follows:
{| class="wikitable"
|-
! Value !! Symbol !! Name
|-
| 0x0 || MP_CAPABLE || Multipath Capable
|-
| 0x1 || MP_JOIN || Join Connection
|-
| 0x2 || DSS || Data Sequence Signal (Data ACK and data sequence mapping)
|-
| 0x3 || ADD_ADDR || Add Address
|-
| 0x4 || REMOVE_ADDR || Remove Address
|-
| 0x5 || MP_PRIO || Change Subflow Priority
|-
| 0x6 || MP_FAIL || Fallback
|-
| 0x7 || MP_FASTCLOSE || Fast Close
|}

Values 0x8 through 0xe are currently unassigned.

==Protocol operation==
Protocol operation is described in detail in RFC 6824.

Congestion control is performed separately for each channel.<ref name="citrix-netscaler" />

==Alternatives==

===Stream Control Transmission Protocol===
[[Stream Control Transmission Protocol]] is a reliable in-order [[datagram]] stream transport protocol originally intended for telecommunication signaling. It supports concurrent use of multiple access links and allows the application to influence the access interface selections on a [[datagram]] stream basis. It also supports mobility via access renegotiation. Hence, SCTP is also a [[transport layer]] solution. It offers type 3 flow granularity with concurrency, but with more flow scheduling control than Multipath TCP. It also fully supports mobility in a fashion similar to Multipath TCP.<ref name=":10">{{cite web|url=http://www-csag.ucsd.edu/projects/Optiputer/papers/2002-rodriguez.pdf
|title=Dynamic parallel access to replicated content in the Internet
|author= P. Rodriguez, E. Biersack
|publisher= IEEE/ACM Transactions on Networking
|date=2002-07-01
}}</ref>

===IMS SIP===
Within the [[IP Multimedia Subsystem|IMS]] architecture, [[Session Initiation Protocol|SIP]] can support the concurrent use of multiple contact IP addresses for the registration of one or more IMS user agents. This allows for the creation of multiple IMS signaling paths. On these signaling paths, signaling messages carry [[Session Description Protocol]] ([[Session Description Protocol|SDP]]) messaging to negotiate media streams. SDP allows for the (re-)negotiation of the streams of one media session over multiple paths. In turn, this enables application layer multipath transport. From this point of view, IMS can therefore offer application layer multipath support with flow granularity and concurrent access. A multipath extension to [[Real-time Transport Protocol|RTP]] is currently under discussion within the IETF. Multipath RTP can offer flow granularity with concurrent access and mobility (via IMS, SDP signaling or the RTP control protocol).<ref name=":10" />

===Other protocols and experiments===
At the session layer, the Mobile Access Router project experimented in 2003 with the aggregation of multiple wireless accesses with heterogeneous technologies, transparently balancing traffic between them in response to the perceived performance of each of them.<ref>{{cite web|url=http://www.cl.cam.ac.uk/research/srg/netos/coms/mar.htm
|title=Mobile Access Router
|author= R. Chakravorty, I. Pratt, P. Rodriguez
|publisher= University of Cambridge, Microsoft Research
|date=2003-07-01
}}</ref>

Parallel access schemes<ref name=":10" /> used to accelerate transfers by taking advantage of [[HTTP request|HTTP 1.1 range requests]] to initiate connections to multiple servers of a replicated content, are not equivalent to Multipath TCP as they involve the application layer and are limited to content of known size.

==RFC==
* RFC 6181 - Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
* RFC 6182 - Architectural Guidelines for Multipath TCP Development
* RFC 6356 - Coupled Congestion Control for Multipath Transport Protocols
* RFC 6824 - TCP Extensions for Multipath Operation with Multiple Addresses
* RFC 6897 - Multipath TCP (MPTCP) Application Interface Considerations

==See also==
* [[Transport Layer#Comparison_of_transport-layer_protocols|Transport protocol comparison table]]

==References==
{{Reflist}}

==External links==
{{Wikiversity | Transmission Control Protocol}}
* [http://mptcp.info.ucl.ac.be/ The Linux Kernel MultiPath TCP project]

[[Category:Transmission Control Protocol| ]]

Wikipedia - Benutzerbeiträge [de]

Multipath TCP