Multipath TCP WG
|Send notices to
The Multipath TCP (MPTCP) working group develops mechanisms that add the
capability of simultaneously using multiple paths to a regular TCP
session. Key goals for MPTCP are: to be deployable and usable without
significant changes to existing Internet infrastructure; to be usable by
unmodified applications; and to be stable and congestion-safe over the
wide range of existing Internet paths, including NAT interactions.
MPTCP assumes that both peers are modified and that one or both peers
have multiple addresses, which often results in different network paths
that are at least partially divergent (however, note there is no
guarantee that the paths are divergent at all).
In its initial charter the WG produced experimental or informational
documents that defined:
a. An architectural framework for congestion-dependent multipath
transport protocols. It describes the motivations and the general
approach that should be followed to enable congestion-dependent
b. A security threat analysis for multipath TCP.
c. A coupled multipath-aware congestion control algorithm. This
algorithm is the multipath equivalent of SACK/NewReno congestion
d. Extensions to current TCP to support multi-addressed multipath TCP.
This covers all on-the-wire changes required to create a two-ended MPTCP
solution using multiple IP addresses at one or both ends. It includes a
basic security solution.
e. Application Interface Considerations. It summarises the impact that
MPTCP may have on applications, such as changes in performance. Also,
it describes an optional, basic application interface for MPTCP-aware
applications that provides access to multipath address information and a
level of control equivalent to regular TCP.
The working group now re-charters to progress various aspects of MPTCP.
The primary goal of the working group is to create a bis version of the
protocol document on the Standards track. This develops the current
Experimental document (item d above), incorporating experience from (for
example) implementations, interoperability events, experiments, usage
scenarios, protocol corner cases, and feedback from TCPM. There already
exists a reference Linux implementation and other implementation and
experimental activity is on-going and will continue during 2012, with
the objective of progressing the protocol to Standards Track during
The working group will also explore and document results with several
of the proposed use cases for MPTCP in more detail, to ensure that
MPTCP works well in practice and that operational experiences and
issues are understood and captured. Likely use cases are to offload
traffic from 3G to WiFi, and to manage traffic within a data centre.
Another scenario is to enable, without changing the MPTCP protocol,
operation of a single-homed, MPTCP end host on a campus network that has
Prior to publishing a Standards Track specification, the working group
will document experimental results and operational experiences to-date.
This should consider not just experience with well-connected fat-pipe
networks and long-lived flows, but also consider a broader links and
types of applications; particularly looking for cases where MPTCP
could be detrimental in some way.
The working group will document implementation advice. The current
documents have several points where an implementer may benefit from
guidance, for example about heuristics such as buffer sizing, or from
advice about alternative implementations such as bump-in-the-stack.
Finally, the working group will explore whether an MPTCP-aware
middlebox would be useful, where at least one end host is MPTCP-enabled.
For example, potentially helping MPTCP's incremental deployment by
allowing only one end host to be MPTCP-enabled and the middlebox acts as
an MPTCP proxy for the other end host, which runs TCP; and potentially
helping some mobility scenarios, where the middlebox acts as an anchor
between two MPTCP-enabled hosts. The working group will detail what real
problems an MPTCP-enabled middlebox might solve, how it would impact the
Multipath TCP architecture (RFC6182), what proxy approach might be
justified as compared against alternative solutions to the problems, and
the likely feasibility of solving the technical and security issues.