Internet Engineering Task Force (IETF) M. Scharf Request for Comments: 6897 Alcatel-Lucent Bell Labs Category: Informational A. Ford ISSN: 2070-1721 Cisco March 2013 Multipath TCP (MPTCP) Application Interface Considerations
AbstractMultipath 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 that is a simple extension of TCP's interface for MPTCP-aware applications. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6897.
Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction ....................................................3 2. Terminology .....................................................4 3. Comparison of MPTCP and Regular TCP .............................5 3.1. Effect on Performance ......................................5 3.1.1. Throughput ..........................................5 3.1.2. Delay ...............................................6 3.1.3. Resilience ..........................................7 3.2. Potential Problems .........................................8 3.2.1. Impact of Middleboxes ...............................8 3.2.2. Dealing with Multiple Addresses inside Applications ........................................9 3.2.3. Security Implications ..............................10 4. Operation of MPTCP with Legacy Applications ....................10 4.1. Overview of the MPTCP Network Stack .......................10 4.2. Address Issues ............................................11 4.2.1. Specification of Addresses by Applications .........11 4.2.2. Querying of Addresses by Applications ..............12 4.3. MPTCP Connection Management ...............................13 4.3.1. Reaction to Close Call by Application ..............13 4.3.2. Other Connection Management Functions ..............13 4.4. Socket Option Issues ......................................13 4.4.1. General Guideline ..................................13 4.4.2. Disabling of the Nagle Algorithm ...................13 4.4.3. Buffer Sizing ......................................14 4.4.4. Other Socket Options ...............................14 4.5. Default Enabling of MPTCP .................................14 4.6. Summary of Advice to Application Developers ...............15
5. Basic API for MPTCP-Aware Applications .........................15 5.1. Design Considerations .....................................15 5.2. Requirements on the Basic MPTCP API .......................16 5.3. Sockets Interface Extensions by the Basic MPTCP API .......17 5.3.1. Overview ...........................................17 5.3.2. Enabling and Disabling of MPTCP ....................19 5.3.3. Binding MPTCP to Specified Addresses ...............19 5.3.4. Querying the MPTCP Subflow Addresses ...............20 5.3.5. Getting a Unique Connection Identifier .............20 6. Other Compatibility Issues .....................................21 6.1. Usage of TLS over MPTCP ...................................21 6.2. Usage of the SCTP Sockets API .............................21 6.3. Incompatibilities with Other Multihoming Solutions ........21 6.4. Interactions with DNS .....................................22 7. Security Considerations ........................................22 8. Conclusion .....................................................23 9. Acknowledgments ................................................23 10. References ....................................................24 10.1. Normative References .....................................24 10.2. Informative References ...................................24 Appendix A. Requirements on a Future Advanced MPTCP API ...........26 A.1. Design Considerations ......................................26 A.2. MPTCP Usage Scenarios and Application Requirements .........27 A.3. Potential Requirements on an Advanced MPTCP API ............29 A.4. Integration with the SCTP Sockets API ......................30 1]. The motivations for this extension include increasing throughput, overall resource utilization, and resilience to network failure, and these motivations are discussed, along with high-level design decisions, as part of the multipath TCP architecture . MPTCP  offers the same reliable, in-order, byte-stream transport as TCP and is designed to be backward compatible with both applications and the network layer. It requires support inside the network stack of both endpoints. This document first presents the effects that MPTCP may have on applications, such as performance changes compared to regular TCP. Second, it defines the interoperation of MPTCP and applications that are unaware of the multipath transport. MPTCP is designed to be usable without any application changes, but some compatibility issues have to be taken into account. Third, this memo specifies a basic Application Programming Interface (API) for MPTCP-aware applications. The API presented here is an extension to the regular TCP API to
allow an MPTCP-aware application the equivalent level of control and access to information of an MPTCP connection that would be possible with the standard TCP API on a regular TCP connection. The de facto standard API for TCP/IP applications is the "sockets" interface . This document provides an abstract definition of MPTCP-specific extensions to this interface. These are operations that can be used by an application to get or set additional MPTCP- specific information on a socket, in order to provide an equivalent level of information and control over MPTCP as exists for an application using regular TCP. It is up to the applications, high- level programming languages, or libraries to decide whether to use these optional extensions. For instance, an application may want to turn on or off the MPTCP mechanism for certain data transfers or limit its use to certain interfaces. The abstract specification is in line with the Portable Operating System Interface (POSIX) standard  as much as possible. An advanced API for MPTCP is outside the scope of this document. Such an advanced API could offer a more fine-grained control over multipath transport functions and policies. The appendix includes a brief, non-compulsory list of potential features of such an advanced API. There can be interactions or incompatibilities of MPTCP with other APIs or sockets interface extensions, which are discussed later in this document. Some network stack implementations, especially on mobile devices, have centralized connection managers or other higher-level APIs to solve multi-interface issues, as surveyed in . Their interaction with MPTCP is outside the scope of this document. The target readers of this document are application developers whose software may benefit significantly from MPTCP. This document also provides the necessary information for developers of MPTCP to implement the API in a TCP/IP network stack. 3]. This document uses the MPTCP terminology introduced in .
Concerning the API towards applications, the following terms are distinguished: o Legacy API: The interface towards TCP that is currently used by applications. This document explains the effect of MPTCP for such applications, as well as resulting issues. o Basic API: A simple extension of TCP's interface for applications that are aware of MPTCP. This document abstractly describes this interface, which provides access to multipath address information and a level of control equivalent to regular TCP. o Advanced API: An API that offers more fine-grained control over the behavior of MPTCP. Its specification is outside the scope of this document. 7]. The following sections summarize the performance effect of MPTCP as seen by an application. 21].
This performance increase additionally means that an MPTCP session could achieve throughput that is greater than the capacity of a single interface on the device. If any applications make assumptions about interfaces due to throughput, they must take this into account (although an MPTCP implementation must always respect an application's request for a particular interface). Furthermore, the flexibility of MPTCP to add and remove subflows as paths change availability could lead to a greater variation, and more frequent change, in connection bandwidth. Applications that adapt to available bandwidth (such as video and audio streaming) may need to adjust some of their assumptions to most effectively take this into account. The transport of MPTCP signaling information results in a small overhead. The use of MPTCP instead of a single TCP connection therefore results in a smaller goodput. Also, if multiple subflows share a same bottleneck, this overhead slightly reduces the capacity that is available for data transport. Yet, this potential reduction of throughput will be negligible in many usage scenarios, and the protocol contains optimizations in its design so that this overhead is minimal.
applications. In general, for a delay-sensitive application, it would be desirable to select an appropriate congestion control algorithm for its traffic needs. Alternatively, MPTCP could be used in high-reliability, rather than high-throughput, modes of operation, such as by mirroring traffic on subflows, or by only using additional subflows for hot standby. These methods of traffic scheduling would not cause delay variation in the same way. These additional modes, and the selection of alternative scheduling algorithms, would need to be indicated by an advanced API, the specification of which requires further analysis and is outside the scope of this document. If data transport on one subflow fails, the retransmissions inside MPTCP could affect the delivery delay to the application. Yet, without MPTCP that data or the whole connection might have been lost, and other reliability mechanisms (e.g., application-level recovery) would likely have an even larger delay impact. In addition, applications that make round-trip time (RTT) estimates at the application level may have some issues. Whilst the average delay calculated will be accurate, whether this is useful for an application will depend on what it requires this information for. If a new application wishes to derive such information, it should consider how multiple subflows may affect its measurements and thus how it may wish to respond. In such a case, an application may wish to express its scheduling preferences, as described later in this document. 5]. Subflow failure may be caused by issues within the network, which an application would be unaware of, or interface failure on the node.
An application may, under certain circumstances, be in a position to be aware of such failure (e.g., by radio signal strength, or simply an interface enabled flag), and so must not make assumptions of an MPTCP flow's stability based on this. An MPTCP implementation must never override an application's request for a given interface, however, so the cases where this issue may be applicable are limited. 22]. Nevertheless, some middleboxes may still refuse to pass MPTCP messages due to the presence of TCP options, or they may strip TCP options. If this is the case, MPTCP falls back to regular TCP. Although this will not create a problem for the application (its communication will be set up either way), there may be additional (and indeed, user- perceivable) delay while the first handshake fails. Therefore, an alternative approach could be to try both MPTCP and regular TCP connection attempts at the same time and respond to whichever replies first, in a fashion similar to the "Happy Eyeballs" mechanism for IPv6 . One could also apply a shorter timeout on the MPTCP attempt and thus reduce the setup delay if fallback to regular TCP is needed. An MPTCP implementation can learn the rate of MPTCP connection attempt successes or failures to particular hosts or networks, and on particular interfaces, and could therefore learn heuristics of when and when not to use MPTCP. A detailed discussion of the various fallback mechanisms, for failures occurring at different points in the connection, is presented in . It must be emphasized that all such heuristics could also fail, and learning can be difficult in certain environments, e.g., if the host is mobile. There may also be middleboxes that transparently change the length of content. If such middleboxes are present, MPTCP's reassembly of the byte stream in the receiver is difficult. Still, MPTCP can detect such middleboxes and then fall back to regular TCP. An overview of the impact of middleboxes is presented in , and MPTCP's mechanisms to work around these issues are presented and discussed in . MPTCP can also have other unexpected implications. For instance, intrusion detection systems could be triggered. A full analysis of MPTCP's impact on such middleboxes is for further study after deployment experiments.
Section 4.2.2). In this case, the IP address exposed to an MPTCP-unaware application can differ from the addresses actually being used by MPTCP. It is even possible that the IP address gets assigned to another host during the lifetime of an MPTCP connection. As further discussed below, this could be an issue if the IP addresses are exchanged by applications, e.g., inside the application protocol. This issue can be addressed by enabling fate- sharing, at the cost of resilience, because the MPTCP connection then cannot close the initial subflow.
6]. Impact on Transport Layer Security (TLS) is discussed in Section 6.1. Figure 1. +-------------------------------+ | Application | +-------------------------------+ ^ | ~~~~~~~~~~|~Sockets Interface|~~~~~~~~~ | v +-------------------------------+ | MPTCP | + - - - - - - - + - - - - - - - + | Subflow (TCP) | Subflow (TCP) | +-------------------------------+ | IP | IP | +-------------------------------+ Figure 1: MPTCP Protocol Stack In general, MPTCP can affect all interfaces that make assumptions about the coupling of a TCP connection to a single IP address and TCP port pair, to one socket endpoint, to one network interface, or to a given path through the network.
This means that there are two classes of applications: o Legacy applications: These applications are unaware of MPTCP and use the existing API towards TCP without any changes. This is the default case. o MPTCP-aware applications: These applications indicate support for an enhanced MPTCP interface. This document specifies a minimum set of API extensions for such applications. In the following sections, it is discussed to what extent MPTCP affects legacy applications using the existing sockets API. The existing sockets API implies that applications deal with data structures that store, amongst others, the IP addresses and TCP port numbers of a TCP connection. A design objective of MPTCP is that legacy applications can continue to use the established sockets API without any changes. However, in MPTCP there is a one-to-many mapping between the socket endpoint and the subflows. This has several subtle implications for legacy applications using sockets API functions. Section 5.3.3). If an application binds to INADDR_ANY, it is assumed that the application does not care which addresses are used locally. In this case, a local policy MAY allow MPTCP to automatically set up multiple subflows on such a connection. The basic sockets API of MPTCP-aware applications allows the expression of further preferences in an MPTCP-compatible way (e.g., binding to a subset of interfaces only).
Section 5.3, in order to retrieve the full list of address pairs for the subflows in use.
5], MPTCP distinguishes between the closing of subflows (by TCP FIN) and closing the whole MPTCP connection (by Data FIN). When an application closes a socket, e.g., by calling the close() function, this indicates that the application has no more data to send, like for single-path TCP. MPTCP will then close the MPTCP connection via Data FIN messages. This is completely transparent for an application. In summary, the semantics of the close() interface for applications are not changed compared to TCP. 5]. These mechanisms provide equivalent functions like single-path TCP and can be mapped accordingly. Therefore, these MPTCP internals do not affect the application interface. 2]. This option is also specified in the POSIX standard . Applications can use this option in combination with MPTCP in exactly the same way. It then SHOULD disable the Nagle algorithm for the MPTCP connection, i.e., all subflows.
In addition, the MPTCP protocol instance MAY use a different path scheduler algorithm if TCP_NODELAY is present. For instance, it could use an algorithm that is optimized for latency-sensitive traffic (for instance, only transmitting on one path). Specific algorithms are outside the scope of this document. 4]. Some network stacks may provide additional implementation-specific socket options or interfaces that affect TCP's behavior. In such cases, implementers must ensure that these options do not interfere with the MPTCP interface.
connection. It may make sense for multiple paths to be brought into operation only after a given period of time, or if the connection is saturated. 5]. o Facilitating stack-internal heuristics: The path management and data scheduling by MPTCP is realized by stack-internal algorithms that may implicitly try to self-optimize their behavior according to assumed application needs. For instance, an MPTCP implementation may use heuristics to determine whether an application requires delay-sensitive or bulk data transport, using, for instance, port numbers, the TCP_NODELAY socket options, or the application's read/write patterns as input parameters. An application developer can facilitate the operation of such heuristics by avoiding atypical interface use cases. For instance, for long bulk data transfers, it does not make sense to enable the TCP_NODELAY socket option, nor is it reasonable to use many small socket send() calls each with small amounts of data only.
An advanced MPTCP API is outside the scope of this document. The basic API does not allow a sender or a receiver to express preferences about the management of paths or the scheduling of data, even if this can have a significant performance impact and if an MPTCP implementation could benefit from additional guidance by applications. A list of potential further API extensions is provided in the appendix. The specification of such an advanced API is for further study and may partly be implementation-specific. MPTCP mainly affects the sending of data. But a receiver may also have preferences about data transfer choices, and it may have performance requirements as well. Yet, the configuration of such preferences is outside of the scope of the basic API. 20]). REQ2: An application should be able to restrict MPTCP to binding to a given set of addresses.
REQ3: An application should be able to obtain information on the pairs of addresses used by the MPTCP subflows. REQ4: An application should be able to extract a unique identifier for the connection (per endpoint). The first requirement is the most important one, since some applications could benefit a lot from MPTCP, but there are also cases in which it hardly makes sense. The existing sockets API provides similar mechanisms to enable or disable advanced TCP features. The second requirement corresponds to the binding of addresses with the bind() socket call, or, e.g., explicit device bindings with a SO_BINDTODEVICE option. The third requirement ensures that there is an equivalent to getpeername() or getsockname() that is able to deal with more than one subflow. Finally, it should be possible for the application to retrieve a unique connection identifier (local to the endpoint on which it is running) for the MPTCP connection. This replaces the (address, port) pair for a connection identifier in single-path TCP, which is no longer static in MPTCP. An application can continue to use getpeername() or getsockname() in addition to the basic MPTCP API. Both functions return the corresponding addresses of the first subflow, as already explained.
o TCP_MULTIPATH_SUBFLOWS: Get the pairs of addresses currently used by the MPTCP subflows o TCP_MULTIPATH_CONNID: Get the local connection identifier for this MPTCP connection Table 1 shows a list of the abstract socket operations for the basic configuration of MPTCP. The first column gives the symbolic name of the operation. The second and third columns indicate whether the operation provides values to be read ("Get") or takes values to configure ("Set"). The fourth column lists the type of data associated with this operation. The data types are listed for information only. In addition to IP addresses, an application MAY also indicate TCP port numbers, as further detailed below. +------------------------+-----+-----+------------------------------+ | Name | Get | Set | Data type | +------------------------+-----+-----+------------------------------+ | TCP_MULTIPATH_ENABLE | o | o | boolean | | TCP_MULTIPATH_ADD | | o | list of addresses | | | | | (and ports) | | TCP_MULTIPATH_REMOVE | | o | list of addresses | | | | | (and ports) | | TCP_MULTIPATH_SUBFLOWS | o | | list of pairs of addresses | | | | | (and ports) | | TCP_MULTIPATH_CONNID | o | | integer | +------------------------+-----+-----+------------------------------+ Table 1: MPTCP Socket Operations There are restrictions on when these new socket operations can be used: o TCP_MULTIPATH_ENABLE: This value should only be set before the establishment of a TCP connection. Its value should only be read after the establishment of a connection. o TCP_MULTIPATH_ADD: This operation can be applied both before connection setup and during a connection. If used before, it controls the local addresses that an MPTCP connection can use. In the latter case, it allows MPTCP to use an additional local address, if there has been a restriction before connection setup. o TCP_MULTIPATH_REMOVE: This operation can be applied both before connection setup and during a connection. In both cases, it removes an address from the list of local addresses that may be used by subflows.
o TCP_MULTIPATH_SUBFLOWS: This value is read-only and can only be used after connection setup. o TCP_MULTIPATH_CONNID: This value is read-only and should only be used after connection setup. Section 4.2.1, if an application enables MPTCP but binds to a specific address or interface, MPTCP MUST be enabled, but MPTCP MUST respect the application's choice and only use addresses that are explicitly provided by the application. Note that it would be possible for an application to use the legacy bindings and then expand on them by using TCP_MULTIPATH_ADD. Note also that it is possible for more than one local address to be initially available to MPTCP in this case, if an application has bound to a specific interface with multiple addresses. An application can disable MPTCP by setting TCP_MULTIPATH_ENABLE to a value of "false". In that case, MPTCP MUST NOT be used on that connection. After connection establishment, an application can get the value of TCP_MULTIPATH_ENABLE. A value of "false" then means lack of MPTCP support. A value of "true" means that MPTCP is supported. Section 5.3.2, MPTCP MUST only use the explicitly specified addresses in that case.
An application MAY also indicate a TCP port number that, if specified, MPTCP MUST attempt to bind to. The port number MAY be different than the one used by existing subflows. If no port number is provided by the application, the port number is automatically selected by the MPTCP implementation, and it is RECOMMENDED that it is the same across all subflows. This operation can also be used to modify the address list in use during the lifetime of an MPTCP connection. In this case, it is used to indicate a set of additional local addresses that the MPTCP connection can make use of and that can be signaled to the peer. It should be noted that this signal is only a hint, and an MPTCP implementation MAY select only a subset of the addresses. The TCP_MULTIPATH_REMOVE operation can be used to remove a local address, or a set of local addresses, from an MPTCP connection. MPTCP MUST close any corresponding subflows (i.e., those using the local address that is no longer present) and signal the removal of the address to the peer. If alternative paths are available using the supplied address list but MPTCP is not currently using them, an MPTCP implementation SHOULD establish alternative subflows before undertaking the address removal. It should be remembered that these operations SHOULD support both IPv4 and IPv6 addresses, potentially in the same call.
17] may be used over MPTCP's basic API. When TLS compares any addresses used by MPTCP against names or addresses present in X.509 certificates  , it MUST only compare them with the address that MPTCP used to start the initial subflow as presented to TLS. The addresses used for subsequent subflows need not to be compared against any TLS certificate information. Finer-grained control would require an advanced API or proactive subflow management via the basic API. 13]. As MPTCP realizes multipath transport from and to multihomed end systems, some of these interface function calls are actually applicable to MPTCP in a similar way. API developers may wish to integrate SCTP and MPTCP calls to provide a consistent interface to the application. Yet, it must be emphasized that the transport service provided by MPTCP is different than that of SCTP, and this is why not all SCTP API functions can be mapped directly to MPTCP. Furthermore, a network stack implementing MPTCP does not necessarily support SCTP and its specific sockets interface extensions. This is why the basic API of MPTCP defines additional socket options only, which are a backward-compatible extension of TCP's application interface. Integration with the SCTP API is outside the scope of the basic API. 11]. Care should be taken that the use of MPTCP not conflict with the overlapping features of other APIs: o SHIM API : This API specifies sockets API extensions for the multihoming shim layer. o HIP API : The Host Identity Protocol (HIP) also results in a new API. o API for Mobile IPv6 : For Mobile IPv6, a significantly extended sockets API exists as well (in addition to API extensions for IPv6 ).
In order to avoid any conflict, multiaddressed MPTCP SHOULD NOT be enabled if a network stack uses SHIM6, HIP, or Mobile IPv6. Furthermore, applications should not try to use both the MPTCP API and another multihoming or mobility layer API. It is possible, however, that some of the MPTCP functionality, such as congestion control, could be used in a SHIM6 or HIP environment. Such operation is for further study. 14]. Specifically, there can be interactions with DNS. Whilst it is expected that an application will iterate over the list of addresses returned from a call such as getaddrinfo(), MPTCP itself MUST NOT make any assumptions about multiple A or AAAA records from the same DNS query referring to the same host, as it is possible that multiple addresses refer to multiple servers for load-balancing purposes. Section 5.3.3, and these threats are further detailed in . The protocol specification of MPTCP  defines several mechanisms to protect MPTCP against those attacks. The syntax and semantics of the API for MPTCP-unaware applications does not change. However, assumptions that non-MPTCP-aware applications may make on the data retrieved by the backward- compatible API are discussed in Section 4.2.2. System administrators may wish to disable MPTCP for certain applications that signal addresses, or make security decisions (e.g., opening firewall holes), based on responses to such queries. In addition, the basic MPTCP API for MPTCP-aware applications defines functions that provide an equivalent level of control and information as exists for regular TCP. This document does not mandate a specific implementation of the basic MPTCP API. The implementation should be designed not to affect memory management assumptions in existing code. Implementors should take into account that data structures will be more complex than for standard TCP, e.g., when multiple
subflow addresses have to be stored. When dealing with such data structures, care is needed not to add security vulnerabilities to applications. New functions enable adding and removing local addresses from an MPTCP connection (TCP_MULTIPATH_ADD and TCP_MULTIPATH_REMOVE). These functions don't add security threats if the MPTCP stack verifies that the addresses provided by the application are indeed available as source addresses for subflows. However, applications should use the TCP_MULTIPATH_ADD function with care, as new subflows might get established to those addresses. Furthermore, it could result in some form of information leakage since MPTCP might advertise those addresses to the other connection endpoint, which could learn IP addresses of interfaces that are not visible otherwise. Use of different addresses should not be assumed to lead to use of different paths, especially for security purposes. MPTCP-aware applications should also take care when querying and using information about the addresses used by subflows (TCP_MULTIPATH_SUBFLOWS). As MPTCP can dynamically open and close subflows, a list of addresses queried once can get outdated during the lifetime of an MPTCP connection. Then, the list may contain invalid entries, i.e., addresses that are not used any more or that might not even be assigned to that host any more. Applications that want to ensure that MPTCP only uses a certain set of addresses should explicitly bind to those addresses. One specific example is the use TLS on top of MPTCP. Corresponding guidance can be found in Section 6.1.
Michael Scharf is supported by the German-Lab project (http://www.german-lab.de/) funded by the German Federal Ministry of Education and Research (BMBF). Alan Ford was previously supported by Roke Manor Research and by Trilogy (http://www.trilogy-project.org/), a research project (ICT-216372) partially funded by the European Community under its Seventh Framework Program.  Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.  Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011.  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013.  Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, March 2011.  Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, October 2011.  "IEEE Standard for Information Technology -- Portable Operating System Interface (POSIX) Base Specifications, Issue 7", IEEE Std. 1003.1-2008, 2008.  Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.  Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for Mobile IPv6", RFC 4584, July 2006.
 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011.  Komu, M. and T. Henderson, "Basic Socket Interface Extensions for the Host Identity Protocol (HIP)", RFC 6317, July 2011.  Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, December 2011.  Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.  Wasserman, M. and P. Seite, "Current Practices for Multiple- Interface Hosts", RFC 6419, November 2011.  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.  Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.  Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.  Sarolahti, P., "Multi-address Interface in the Socket API", Work in Progress, March 2010.  Khalili, R., Gast, N., Popovic, M., and J. Le Boudec, "Performance Issues with MPTCP", Work in Progress, February 2013.  Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it Still Possible to Extend TCP?", Proc. ACM Internet Measurement Conference (IMC), November 2011.
Section 6.1) that requires further work. Furthermore, an advanced MPTCP API could be part of a new overall interface between the network stack and applications that addresses other issues as well, such as the split between identifiers and locators. An API that does not use IP addresses (but instead uses, e.g., the connectbyname() function) would be useful for numerous purposes, independent of MPTCP. It has also been suggested that a separate address family called AF_MULTIPATH  be used. This separate address family could be used to exchange multiple addresses between an application and the standard sockets API, but it would be a more fundamental change compared to the basic API described in this document. This appendix documents a list of potential usage scenarios and requirements for the advanced API. The specification and implementation of a corresponding API are outside the scope of this document.
A further, mostly orthogonal question is whether data should be duplicated over the different subflows, in particular if there is spare capacity. This could improve both the timeliness and reliability of data delivery. In summary, there are at least three possible performance objectives for multipath transport: 1. High bandwidth 2. Low latency and jitter stability 3. High reliability These are not necessarily disjoint, since there are also broadband interactive applications that require both high-speed bulk data traffic and a low latency and jitter. In an advanced API, applications could provide high-level guidance to the MPTCP implementation concerning these performance requirements, for instance, which requirement is considered to be the most important. The MPTCP stack would then use internal mechanisms to fulfill this abstract indication of a desired service, as far as possible. This would affect the assignment of data (including retransmissions) to existing subflows (e.g., 'use all in parallel', 'use as overflow', 'hot standby', 'duplicate traffic') as well as the decisions regarding when to set up additional subflows to which addresses. In both cases, different policies can exist, which can be expected to be implementation-specific. Therefore, an advanced API could provide a mechanism for how applications can specify their high-level requirements in an implementation-independent way. One possibility would be to select one "application profile" out of a number of choices that characterize typical applications. Yet, as applications today do not have to inform TCP about their communication requirements, it requires further studies as to whether such an approach would be realistic. Of course, independent of an advanced API, such functionality could also partly be achieved by MPTCP-internal heuristics that infer some application preferences, e.g., from existing socket options, such as TCP_NODELAY. Whether this would be reliable, and indeed appropriate, is for further study.
REQ12: An application should be able to control the level of redundancy by telling whether segments should be sent on more than one path in parallel. REQ13: An application should be able to control the use of fate- sharing of the MPTCP connection and the initial subflow, e.g., to overwrite system policies. REQ14: An application should be able to register for callbacks to be informed of changes to subflows on an MPTCP connection. This "push" interface would allow the application to make timely logging and configuration changes, if required, and would avoid frequent polling of information. An advanced API fulfilling these requirements would allow application developers to more specifically configure MPTCP. It could avoid suboptimal decisions of internal, implicit heuristics. However, it is unclear whether all of these requirements would have a significant benefit to applications, since they are going above and beyond what the existing API to regular TCP provides. A subset of these functions might also be implemented system-wide or by other configuration mechanisms. These implementation details are left for further study. 13]. A potential objective for the advanced API is to provide a consistent MPTCP and SCTP interface to the application. This is left for further study.