* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Mptcp Status Pages

Multipath TCP (Concluded WG)
Tsv Area: Zaheduzzaman Sarker, Martin Duke | 2009-Oct-15 — 2020-Mar-17 

2020-01-10 charter

Multipath TCP (mptcp)


 Current Status: Active

     Philip Eardley <philip.eardley@bt.com>
     Yoshifumi Nishida <nsd.ietf@gmail.com>

 Transport Area Directors:
     Mirja K├╝hlewind <ietf@kuehlewind.net>
     Magnus Westerlund <magnus.westerlund@ericsson.com>

 Transport Area Advisor:
     Mirja K├╝hlewind <ietf@kuehlewind.net>

 Mailing Lists:
     General Discussion: multipathtcp@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/multipathtcp
     Archive:            https://mailarchive.ietf.org/arch/browse/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.  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
  multipath transport.

  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
  multiple providers.

  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.

Goals and Milestones:
  Nov 2017 - Enhanced API (Informational) to IESG
  Mar 2018 - MPTCP standards track protocol to IESG
  Apr 2018 - Re-charter or close
  Done     - Established WG consensus on the Architecture
  Done     - Submit to IESG architectural guidelines and security threat analysis as informational RFC(s)
  Done     - Submit to IESG basic coupled congestion control as an experimental RFC
  Done     - Consensus on what high-level changes are needed to the current MPTCP Experimental document in order to progress it on the standards track
  Done     - Use-cases and operational experiences (Informational) to IESG

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/mptcp/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -