A new IETF working group has been formed in the Transport Area. For additional information, please contact the Area Directors or the WG Chairs. Multipath TCP (mptcp) --------------------------------------------------- Current Status: Active Working Group Chairs: Philip Eardley (philip.eardley@bt.com) Yoshifumi Nishida (nishida@sfc.wide.ad.jp) Transport Area Directors: Magnus Westerlund (magnus.westerlund@ericsson.com) Lars Eggert (lars.eggert@nokia.com) Transport Area Advisor: Magnus Westerlund (magnus.westerlund@ericsson.com) Mailing Lists: General Discussion: multipathtcp@ietf.org 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. 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 documented. 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 interfaces. Goals and Milestones: Mar 2010 Established WG consensus on the Architecture Aug 2010 Submit to IESG architectural guidelines and security threat analysis as informational RFC(s) Mar 2011 Submit to IESG basic coupled congestion control as an experimental RFC Mar 2011 Submit to IESG protocol specification for MPTCP extensions as an experimental RFC Mar 2011 Submit to IESG an extended API for MPTCP as an or part of an experimental or informational RFC Mar 2011 Submit to IESG application considerations as an informational RFC Mar 2011 Recharter or close WG _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
