Subject: [multipathtcp] WG Action: Rechartered Multipath TCP (mptcp)

From: The IESG <[email-masked]>
Date: Thu, 21 Jun 2012 12:41:46 -0700

The Multipath TCP (mptcp) working group in the Transport Area of the IETF
has been rechartered. For additional information please contact the Area
Directors or the WG Chairs.

Multipath TCP (mptcp)
------------------------------------------------
Current Status: Active Working Group

Chairs:
  Philip Eardley <[email-masked]>
  Yoshifumi Nishida <[email-masked]>

Assigned Area Director:
  Wesley Eddy <[email-masked]>

Mailing list
  Address: [email-masked]
  To Subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp
  Archive: http://www.ietf.org/mail-archive/web/multipathtcp/

Charter 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
control.

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
2013.

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.

Milestones:
  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
  Dec 2012 - Consensus on what high-level changes are needed to the
current MPTCP Experimental document in order to progress it on the
standards track
  Apr 2013 - Implementation advice (Informational) to IESG
  Aug 2013 - Use-cases and operational experiences (Informational) to
IESG
  Dec 2013 - MPTCP-enabled middleboxes (Informational) to IESG
  Dec 2013 - MPTCP standards track protocol to IESG
  Jan 2014 - Re-charter or close