Skip to main content

Multipath TCP

The information below is for an older approved charter
Document Charter Multipath TCP WG (mptcp) Snapshot
Title Multipath TCP
Last updated 2009-10-15
State Approved
WG State Concluded
IESG Responsible AD Mirja K├╝hlewind
Charter edit AD (None)
Send notices to (None)

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