2.8.5 Multipath TCP (mptcp)
NOTE: This charter is a snapshot of the 75th IETF Meeting in Stockholm, Sweden. It may now be out-of-date.
Last Modified: 2009-10-19
Yoshifumi Nishida <firstname.lastname@example.org>
Philip Eardley <email@example.com>
Transport Area Director(s):
Magnus Westerlund <firstname.lastname@example.org>
Lars Eggert <email@example.com>
Transport Area Advisor:
Magnus Westerlund <firstname.lastname@example.org>
General Discussion: email@example.com
To Subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp
Description of Working Group:
The Multipath TCP (MPTCP) working group develops mechanisms that add the
capability of simultaneously using multiple paths to a regular TCP
session. The primary output of the group will be the protocol extensions
needed to deploy MPTCP, and adaptations to congestion control to safely
support multipath resource sharing. Initially the WG will only produce
documents that are experimental or informational.
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. That will include handling MTU discovery on
a per path basis and NAT interactions. The design's success in meeting
the goals should be determined through experiments. However, it is
expected that some results from large scale experiments can only be
achievable after the publication of the initial design.
The working group will provide a modular architecture that is designed
to be easily extensible and adaptable. In particular, the congestion
control mechanism is separated from the mechanisms for identifying and
using multiple paths. The working group will focus on a solution
requiring modification of both peers. One or both peers are expected to
have multiple addresses, which often results in different network paths
that are at least partially divergent. However, multiple addresses, even
on different network interfaces, are no guarantee that the paths are
divergent at all. The design needs to address the issues associated with
fully or partially joint paths and shared bottlenecks. The design should
allow for future extensions to handle cases where path diversity is
attempted through other means than using different addresses. The design
must also consider what happens when an end-point pair becomes
unavailable during an ongoing session, especially a pair that has been
used to establish an additional path (for this connection) between
another end-point pair.
Whilst MPTCP will require modifications to the TCP stack at both the
peers, all existing applications should be able to use the new MPTCP
stack without modification and gain benefits from multipath usage. The
impact on different classes of applications will be considered and
documented. An extended API will be defined to allow applications to
express particular preferences for how MPTCP operates, and to get
additional information about MPTCP-specific run-time events.
The WG will carefully analyze and address in the appropriate protocol
documents all new security threats introduced by MPTCP.
The following items will be worked on:
a. An architectural framework for congestion-dependent multipath
transport protocols. This is an overview document which tracks the
technical documents, describing how the modular components fit together,
and will describe the motivations and the general approach that should
be followed to enable congestion-dependent multipath transport. It will
also analyze how MPTCP interacts with existing infrastructure elements
and other address agility mechanisms, such as Mobile IP, HIP and SHIM6.
The results of any experiment performed during the development should
also be included or referenced in this document.
b. A security threat analysis for multipath TCP. The ability to change
the addresses used during a TCP session opens up new types of
vulnerabilities and attacks. These and their mitigations will be
c. A coupled multipath-aware congestion control algorithm. This
algorithm is the multipath equivalent of SACK/NewReno congestion
control. As experience is gathered from implementations of various
congestion control algorithms, it is expected that the working group
will be rechartered to pursue additional work in these areas.
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 addresses at one or both ends. It will be
designed in a modular fashion to allow alternative address management
schemes to be explored in future. This document will also include a
basic security model.
e. An extended API describing how applications can exploit additional
features of multipath transport. While MPTCP needs to be usable without
any application changes, this API should be an optional extension that
provides access to multipath information and enables control over the
usage of multipath.
f. An application considerations document, presenting the impacts that
MPTCP may have on applications, such as performance changes. It should
also discuss issues it create for applications, such as its effects on
the usage of IPsec.
Where appropriate, this group is expected to coordinate with, and will
use input from, the MIF working group to support the use of multiple
Goals and Milestones:
|Mar 2010|| ||Established WG consensus on the Architecture |
|Aug 2010|| ||Submit to IESG architectural guidelines and security threat
analysis as informational RFC(s) |
|Mar 2011|| ||Submit to IESG basic coupled congestion control as an
experimental RFC |
|Mar 2011|| ||Submit to IESG protocol specification for MPTCP extensions as
an experimental RFC |
|Mar 2011|| ||Submit to IESG an extended API for MPTCP as an or part of an
experimental or informational RFC |
|Mar 2011|| ||Submit to IESG application considerations as an informational
|Mar 2011|| ||Recharter or close WG |
No Current Internet-Drafts
No Request For Comments
Agenda, Intro, Chartering
Multipath TCP: Goals and Background
Linked Congestion Control
Rethinking the Transport Layer