[secdir] [new-work] WG Review: Recharter of Multipath TCP (mptcp)

[IESG Secretary <[e-mail]>]

A modified charter has been submitted for the Multipath TCP (mptcp) 
working group in the Transport Area of the IETF.  The IESG has not made 
any determination as yet.  The modified charter is provided below for 
informational purposes only.  Please send your comments to the IESG 
mailing list ([e-mail]) by Tuesday, May 22, 2012.

Multipath TCP (mptcp)
----------------------------------------------------------
Status: Active Working Group
Last updated: 2012-05-10

Chairs:
    Philip Eardley <[e-mail]>
    Yoshifumi Nishida <[e-mail]>

Transport Area Directors:
    Wesley Eddy <[e-mail]>
    Martin Stiemerling <[e-mail]>

Transport Area Advisor:
    Wesley Eddy <[e-mail]>

Mailing List: 
 Address:	[e-mail]
 To Subscribe:	https://www.ietf.org/mailman/listinfo/multipathtcp
 Archive:	http://www.ietf.org/mail-archive/web/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
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 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.

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.

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:

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

April 2013  Implementation advice (Informational) to IESG

August 2013 Use cases (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
_______________________________________________
new-work mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/new-work