|Document||Charter||Multipath TCP WG (mptcp)|
|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. 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.