Multipath TCP (MPTCP) Application Interface Considerations
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, mptcp mailing list <firstname.lastname@example.org>, mptcp chair <email@example.com> Subject: Document Action: 'MPTCP Application Interface Considerations' to Informational RFC (draft-ietf-mptcp-api-07.txt) The IESG has approved the following document: - 'MPTCP Application Interface Considerations' (draft-ietf-mptcp-api-07.txt) as Informational RFC This document is the product of the Multipath TCP Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mptcp-api/
Technical Summary Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface which is a simple extension of TCP's interface for MPTCP-aware applications. Working Group Summary The document was not particularly controversial. There was very good consensus in the WG about the document. The document has been stable for quite a while, since it was decided to advance it in parallel with the MPTCP protocol. Document Quality The dcoument has been reviewed within the WG. Michael Tüxen (SCTP author) provided an expert review. There was also a WG last call, which resulted in some clarifications. An implementation of the protocol is publicly available, and other implementations are in progress. The API for MPTCP-aware applications has not been implemented to our knowledge. Personnel The document shepherd is Philip Eardley. The Responsible Area Director is Wes Eddy.