diff options
Diffstat (limited to 'doc/rfc/rfc6897.txt')
| -rw-r--r-- | doc/rfc/rfc6897.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc6897.txt b/doc/rfc/rfc6897.txt new file mode 100644 index 0000000..1dcf155 --- /dev/null +++ b/doc/rfc/rfc6897.txt @@ -0,0 +1,1739 @@ + + + + + + +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 + +Abstract + + 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 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. + + + + + + + + + + + + + + +Scharf & Ford Informational [Page 1] + +RFC 6897 MPTCP API March 2013 + + +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. + +Table of Contents + + 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 + + + + + + + +Scharf & Ford Informational [Page 2] + +RFC 6897 MPTCP API March 2013 + + + 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. Introduction + + Multipath TCP adds the capability of using multiple paths to a + regular TCP session [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 [4]. MPTCP [5] 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 + + + + + +Scharf & Ford Informational [Page 3] + +RFC 6897 MPTCP API March 2013 + + + 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 [8]. 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 + [8] 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 + [15]. 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. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [3]. + + This document uses the MPTCP terminology introduced in [5]. + + + + + + + +Scharf & Ford Informational [Page 4] + +RFC 6897 MPTCP API March 2013 + + + 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. + +3. Comparison of MPTCP and Regular TCP + + This section discusses the effect of MPTCP on performance as seen by + an application, in comparison to what may be expected from the use of + regular TCP. + +3.1. Effect on Performance + + One of the key goals of adding multipath capability to TCP is to + improve the performance of a transport connection by load + distribution over separate subflows across potentially disjoint + paths. Furthermore, it is an explicit goal of MPTCP that it provides + a connection that performs at least as well as one using single-path + TCP. A corresponding congestion control algorithm is described in + [7]. The following sections summarize the performance effect of + MPTCP as seen by an application. + +3.1.1. Throughput + + The most obvious performance improvement that can be expected from + the use of MPTCP is an increase in throughput, since MPTCP will pool + more than one path (where available) between two endpoints. This + will usually provide as great or greater bandwidth for an + application, even though exceptions may exist, e.g., due to + differences in the congestion control dynamics. For instance, if a + new subflow is started, the short-term throughput can be smaller than + the theoretical optimum. If there are shared bottlenecks between the + flows, then the congestion control algorithms will in most cases + ensure that load is evenly spread amongst regular and multipath TCP + sessions, so that no end user receives worse performance than if all + were using single-path TCP. There are some known corner cases in + which an upgrade to MPTCP can affect other users [21]. + + + +Scharf & Ford Informational [Page 5] + +RFC 6897 MPTCP API March 2013 + + + 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. + +3.1.2. Delay + + The benefits of MPTCP regarding throughput and resilience may come at + some cost regarding data delivery delay and delay jitter. + + If the delays on the constituent subflows of an MPTCP connection + differ, the jitter perceivable to an application may appear higher as + the data are spread across the subflows. Although MPTCP will ensure + in-order delivery to the application, the data delivery could be more + bursty than may be usual with single-path TCP, in particular on + highly asymmetric paths. + + Applications with high real-time requirements might be affected by + such a scenario. One possible remedy is to disable MPTCP for such + jitter-sensitive applications, either by using the basic API defined + in this document, or by other means, such as system policies. + + However, the actual delay and jitter of data transport over MPTCP + depend on the scheduling and congestion control algorithms used for + sending data, as well as the heuristics to establish and shut down + subflows. A sender can implement strategies to minimize the delay + jitter seen by applications, but this requires an accurate estimation + of the path characteristics. If the scheduling decisions are + suboptimal or if assumptions about the path characteristics turn out + to be wrong, delay jitter may be increased and affect delay-sensitive + + + +Scharf & Ford Informational [Page 6] + +RFC 6897 MPTCP API March 2013 + + + 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. + +3.1.3. Resilience + + Another performance improvement through the use of MPTCP is better + resilience. The use of multiple subflows simultaneously means that + if one should fail, all traffic will move to the remaining + subflow(s), and additionally any lost packets can be retransmitted on + these subflows. + + As one special case, MPTCP can be used with only one active subflow + at a given point in time. In that case, resilience compared to + single-path TCP is improved. MPTCP also supports make-before-break + and break-before-make handovers between subflows. In both cases, the + MPTCP connection can survive an unavailability or change of an IP + address (e.g., due to shutdown of an interface or handover). MPTCP + closes or resets the MPTCP connection separately from the individual + subflows, as described in [5]. + + Subflow failure may be caused by issues within the network, which an + application would be unaware of, or interface failure on the node. + + + +Scharf & Ford Informational [Page 7] + +RFC 6897 MPTCP API March 2013 + + + 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. + +3.2. Potential Problems + +3.2.1. Impact of Middleboxes + + MPTCP has been designed to pass through the majority of middleboxes. + Empirical evidence suggests that new TCP options can successfully be + used on most paths in the Internet [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 [16]. 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 [5]. 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 [4], and MPTCP's mechanisms + to work around these issues are presented and discussed in [5]. + + 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. + + + + +Scharf & Ford Informational [Page 8] + +RFC 6897 MPTCP API March 2013 + + +3.2.2. Dealing with Multiple Addresses inside Applications + + In regular TCP, there is a one-to-one mapping of the sockets + interface to a flow through a network. Since MPTCP can make use of + multiple subflows, applications cannot implicitly rely on this + one-to-one mapping any more. + + Whilst this doesn't matter for most applications, some applications + may need to adapt to the presence of multiple addresses, because + implicit assumptions are outdated. In this section, selected + examples for resulting issues are discussed. The question of whether + such implicit assumptions matter is an application-level decision, + and this document only provides general guidance and a basic API to + retrieve relevant information. + + A few applications require the transport to be along a single path; + they can disable the use of MPTCP as described later in this + document. Examples include monitoring tools that want to measure the + available bandwidth on a path, or routing protocols such as BGP that + require the use of a specific link. + + Certain applications store the IP addresses of TCP connections, e.g., + by logging mechanisms. Such logging mechanisms will continue to work + with MPTCP, but two important aspects have to be mentioned: First, if + the application is not aware of MPTCP, it will use the existing + interface to the network stack. This implies that an MPTCP-unaware + application will track the IP addresses of the first subflow only. + IP addresses used by follow-up subflows will be ignored. Second, an + MPTCP-aware application can use the basic API described in this + document to monitor the IP addresses of all subflows, e.g., for + logging mechanisms. If an MPTCP connection uses several subflows, + this will possibly imply that data structures have to be adapted and + that the amount of data that has to be logged and stored per + connection will increase. + + An MPTCP implementation may choose to maintain an MPTCP connection + even if the IP address of the original subflow is no longer allocated + to a host, depending on the policy concerning the first subflow + (fate-sharing; see 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. + + + + +Scharf & Ford Informational [Page 9] + +RFC 6897 MPTCP API March 2013 + + +3.2.3. Security Implications + + The support for multiple IP addresses within one MPTCP connection can + result in additional security vulnerabilities, such as possibilities + for attackers to hijack connections. The protocol design of MPTCP + minimizes this risk. An attacker on one of the paths can cause harm, + but this is hardly an additional security risk compared to single- + path TCP, which is vulnerable to man-in-the-middle attacks as well. + A detailed threat analysis of MPTCP is published in [6]. + + Impact on Transport Layer Security (TLS) is discussed in Section 6.1. + +4. Operation of MPTCP with Legacy Applications + +4.1. Overview of the MPTCP Network Stack + + MPTCP is an extension of TCP, but it is designed to be backward + compatible for legacy (MPTCP-unaware) applications. TCP interacts + with other parts of the network stack via different interfaces. The + de facto standard API between TCP and applications is the sockets + interface. The position of MPTCP in the protocol stack is + illustrated in 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. + + + + + + + + +Scharf & Ford Informational [Page 10] + +RFC 6897 MPTCP API March 2013 + + + 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. + +4.2. Address Issues + +4.2.1. Specification of Addresses by Applications + + During binding, an application can either select a specific address + or bind to INADDR_ANY. Furthermore, on some systems other socket + options (e.g., SO_BINDTODEVICE) can be used to bind to a specific + interface. If an application uses a specific address or binds to a + specific interface, then MPTCP MUST respect this and not interfere in + the application's choices. The binding to a specific address or + interface implies that the application is not aware of MPTCP and will + disable the use of MPTCP on this connection. An application that + wishes to bind to a specific set of addresses with MPTCP must use + multipath-aware calls to achieve this (as described in + 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). + + + + + + +Scharf & Ford Informational [Page 11] + +RFC 6897 MPTCP API March 2013 + + +4.2.2. Querying of Addresses by Applications + + Applications can use the getpeername() or getsockname() functions in + order to retrieve the IP address of the peer or of the local socket. + These functions can be used for various purposes, including security + mechanisms, geo-location, or interface checks. The sockets API was + designed with an assumption that a socket is using just one address, + and since this address is visible to the application, the application + may assume that the information provided by the functions is the same + during the lifetime of a connection. However, in MPTCP, unlike in + TCP, there is a one-to-many mapping of a connection to subflows, and + subflows can be added and removed while the connection continues to + exist. Since the subflow addresses can change, MPTCP cannot expose + addresses by getpeername() or getsockname() that are both valid and + constant during the connection's lifetime. + + This problem is addressed as follows: If used by a legacy + application, the MPTCP stack MUST always return the addresses and + port numbers of the first subflow of an MPTCP connection, in all + circumstances, even if that particular subflow is no longer in use. + + As the addresses may not be valid any more if the first subflow is + closed, the MPTCP stack MAY close the whole MPTCP connection if the + first subflow is closed (i.e., fate-sharing between the initial + subflow and the MPTCP connection as a whole). This fate-sharing + avoids the reuse of the pair of IP addresses and ports while an MPTCP + connection is still in progress, but at the cost of reducing the + utility of MPTCP if IP addresses of the first subflow are not + available any more (e.g., mobility events). Whether to close the + whole MPTCP connection by default SHOULD be controlled by a local + policy. Further experiments are needed to investigate its + implications. + + The functions getpeername() and getsockname() SHOULD also always + return the addresses of the first subflow if the socket is used by an + MPTCP-aware application, in order to be consistent with MPTCP-unaware + applications, and, e.g., also with the Stream Control Transmission + Protocol (SCTP). Instead of getpeername() or getsockname(), + MPTCP-aware applications can use new API calls, described in + Section 5.3, in order to retrieve the full list of address pairs for + the subflows in use. + + + + + + + + + + +Scharf & Ford Informational [Page 12] + +RFC 6897 MPTCP API March 2013 + + +4.3. MPTCP Connection Management + +4.3.1. Reaction to Close Call by Application + + As described in [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. + +4.3.2. Other Connection Management Functions + + In general, an MPTCP connection is maintained separately from + individual subflows. MPTCP therefore has internal mechanisms to + establish, close, or reset the MPTCP connection [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. + +4.4. Socket Option Issues + +4.4.1. General Guideline + + The existing sockets API includes options that modify the behavior of + sockets and their underlying communications protocols. Various + socket options exist on the socket, TCP, and IP level. The value of + an option can usually be set by the setsockopt() system function. + The getsockopt() function gets information. In general, the existing + sockets interface functions cannot configure each MPTCP subflow + individually. In order to be backward compatible, existing APIs + therefore SHOULD apply to all subflows within one connection, as far + as possible. + +4.4.2. Disabling of the Nagle Algorithm + + One commonly used TCP socket option (TCP_NODELAY) disables the Nagle + algorithm as described in [2]. This option is also specified in the + POSIX standard [8]. 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. + + + + +Scharf & Ford Informational [Page 13] + +RFC 6897 MPTCP API March 2013 + + + 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.4.3. Buffer Sizing + + Applications can explicitly configure send and receive buffer sizes + via the sockets API (SO_SNDBUF, SO_RCVBUF). These socket options can + also be used in combination with MPTCP and then affect the buffer + size of the MPTCP connection. However, when defining buffer sizes, + application programmers should take into account that the transport + over several subflows requires a certain amount of buffer for + resequencing in the receiver. MPTCP may also require more storage + space in the sender, in particular, if retransmissions are sent over + more than one path. In addition, very small send buffers may prevent + MPTCP from efficiently scheduling data over different subflows. + Therefore, it does not make sense to use MPTCP in combination with + small send or receive buffers. + + An MPTCP implementation MAY set a lower bound for send and receive + buffers and treat a small buffer size request as an implicit request + not to use MPTCP. + +4.4.4. Other Socket Options + + TCP features the ability to send "Urgent" data, but its use is not + recommended in general, and specifically not with MPTCP [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. + +4.5. Default Enabling of MPTCP + + It is up to a local policy at the end system whether a network stack + should automatically enable MPTCP for sockets even if there is no + explicit sign of MPTCP awareness of the corresponding application. + Such a choice may be under the control of the user through system + preferences. + + The enabling of MPTCP, either by application or by system defaults, + does not necessarily mean that MPTCP will always be used. Both + endpoints must support MPTCP, and there must be multiple addresses at + at least one endpoint, for MPTCP to be used. Even if those + requirements are met, however, MPTCP may not be immediately used on a + + + +Scharf & Ford Informational [Page 14] + +RFC 6897 MPTCP API March 2013 + + + 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. + +4.6. Summary of Advice to Application Developers + + o Using the default MPTCP configuration: Like TCP, MPTCP is designed + to be efficient and robust in the default configuration. + Application developers should not explicitly configure TCP (or + MPTCP) features unless this is really needed. + + o Socket buffer dimensioning: Multipath transport requires larger + buffers in the receiver for resequencing, as already explained. + Applications should use reasonable buffer sizes (such as the + operating system default values) in order to fully benefit from + MPTCP. A full discussion of buffer sizing issues is given in [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. + +5. Basic API for MPTCP-Aware Applications + +5.1. Design Considerations + + While applications can use MPTCP with the unmodified sockets API, + multipath transport results in many degrees of freedom. MPTCP + manages the data transport over different subflows automatically. By + default, this is transparent to the application, but an application + could use an additional API to interface with the MPTCP layer and to + control important aspects of the MPTCP implementation's behavior. + + This document describes a basic MPTCP API. The API contains a + minimum set of functions that provide an equivalent level of control + and information as exists for regular TCP. It maintains backward + compatibility with legacy applications. + + + + +Scharf & Ford Informational [Page 15] + +RFC 6897 MPTCP API March 2013 + + + 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. + +5.2. Requirements on the Basic MPTCP API + + Because of the importance of the sockets interface there are several + fundamental design objectives for the basic interface between MPTCP + and applications: + + o Consistency with existing sockets APIs must be maintained as far + as possible. In order to support the large base of applications + using the original API, a legacy application must be able to + continue to use standard sockets interface functions when run on a + system supporting MPTCP. Also, MPTCP-aware applications should be + able to access the socket without any major changes. + + o Sockets API extensions must be minimized and independent of an + implementation. + + o The interface should handle both IPv4 and IPv6. + + The following is a list of the core requirements for the basic API: + + REQ1: Turn on/off MPTCP: An application should be able to request to + turn on or turn off the usage of MPTCP. This means that an + application should be able to explicitly request the use of + MPTCP if this is possible. Applications should also be able + to request not to enable MPTCP and to use regular TCP + transport instead. This can be implicit in many cases, since + MPTCP must be disabled by the use of binding to a specific + address. MPTCP may also be enabled if an application uses a + dedicated multipath address family (such as AF_MULTIPATH + [20]). + + REQ2: An application should be able to restrict MPTCP to binding to + a given set of addresses. + + + + +Scharf & Ford Informational [Page 16] + +RFC 6897 MPTCP API March 2013 + + + 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. + +5.3. Sockets Interface Extensions by the Basic MPTCP API + +5.3.1. Overview + + The abstract, basic MPTCP API consists of a set of new values that + are associated with an MPTCP socket. Such values may be used for + changing properties of an MPTCP connection or retrieving information. + These values could be accessed by new symbols on existing calls such + as setsockopt() and getsockopt() or could be implemented as entirely + new function calls. This implementation decision is out of scope for + this document. The following list presents symbolic names for these + MPTCP socket settings. + + o TCP_MULTIPATH_ENABLE: Enable/disable MPTCP + + o TCP_MULTIPATH_ADD: Bind MPTCP to a set of given local addresses, + or add a set of new local addresses to an existing MPTCP + connection + + o TCP_MULTIPATH_REMOVE: Remove a local address from an MPTCP + connection + + + + + + +Scharf & Ford Informational [Page 17] + +RFC 6897 MPTCP API March 2013 + + + 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. + + + + +Scharf & Ford Informational [Page 18] + +RFC 6897 MPTCP API March 2013 + + + 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. + +5.3.2. Enabling and Disabling of MPTCP + + An application can explicitly indicate multipath capability by + setting TCP_MULTIPATH_ENABLE to the value "true". In this case, the + MPTCP implementation SHOULD try to negotiate MPTCP for that + connection. Note that multipath transport will not necessarily be + enabled, as it requires support at both end systems, no middleboxes + on the path that would prevent any additional signaling, and at least + one endpoint with multiple addresses. + + Building on the backward compatibility specified in 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. + +5.3.3. Binding MPTCP to Specified Addresses + + Before connection establishment, an application can use the + TCP_MULTIPATH_ADD function to indicate a set of local IP addresses + that MPTCP may bind to. The parameter of the function is a list of + addresses in a corresponding data structure. By extension, this + operation will also control the list of addresses that can be + advertised to the peer via MPTCP signaling. + + If an application binds to a specific address or interface, it is not + required to use the TCP_MULTIPATH_ADD operation for that address. As + explained in Section 5.3.2, MPTCP MUST only use the explicitly + specified addresses in that case. + + + +Scharf & Ford Informational [Page 19] + +RFC 6897 MPTCP API March 2013 + + + 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. + +5.3.4. Querying the MPTCP Subflow Addresses + + An application can get a list of the addresses used by the currently + established subflows in an MPTCP connection by means of the read-only + TCP_MULTIPATH_SUBFLOWS operation. + + The return value is a list of pairs of tuples of IP address and TCP + port number. In one pair, the first tuple refers to the local IP + address and the local TCP port, and the second one to the remote IP + address and remote TCP port used by the subflow. The list MUST only + include established subflows. Both addresses in each pair MUST be + either IPv4 or IPv6. + +5.3.5. Getting a Unique Connection Identifier + + An application that wants a unique identifier for the connection, + analogous to an (address, port) pair in regular TCP, can query the + TCP_MULTIPATH_CONNID value to get a local connection identifier for + the MPTCP connection. + + This SHOULD be an integer number and SHOULD be locally unique (e.g., + the MPTCP token). + + + +Scharf & Ford Informational [Page 20] + +RFC 6897 MPTCP API March 2013 + + +6. Other Compatibility Issues + +6.1. Usage of TLS over MPTCP + + Transport Layer Security (TLS) [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 [18] [19], 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. + +6.2. Usage of the SCTP Sockets API + + For dealing with multihoming, several sockets API extensions have + been defined for SCTP [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. + +6.3. Incompatibilities with Other Multihoming Solutions + + The use of MPTCP can interact with various related sockets API + extensions. The use of a multihoming shim layer conflicts with + multipath transport such as MPTCP or SCTP [11]. Care should be taken + that the use of MPTCP not conflict with the overlapping features of + other APIs: + + o SHIM API [11]: This API specifies sockets API extensions for the + multihoming shim layer. + + o HIP API [12]: The Host Identity Protocol (HIP) also results in a + new API. + + o API for Mobile IPv6 [10]: For Mobile IPv6, a significantly + extended sockets API exists as well (in addition to API extensions + for IPv6 [9]). + + + +Scharf & Ford Informational [Page 21] + +RFC 6897 MPTCP API March 2013 + + + 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. + +6.4. Interactions with DNS + + In multihomed or multiaddressed environments, there are various + issues that are not specific to MPTCP but have to be considered as + well. These problems are summarized in [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. + +7. Security Considerations + + This document first defines the behavior of the standard TCP/IP API + for MPTCP-unaware applications. In general, enabling MPTCP has some + security implications for applications, which are introduced in + Section 5.3.3, and these threats are further detailed in [6]. The + protocol specification of MPTCP [5] 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 + + + + + +Scharf & Ford Informational [Page 22] + +RFC 6897 MPTCP API March 2013 + + + 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. + +8. Conclusion + + This document discusses MPTCP's implications and its performance + impact on applications. In addition, it specifies a basic MPTCP API. + For legacy applications, it is ensured that the existing sockets API + continues to work. MPTCP-aware applications can use the basic MPTCP + API that provides some control over the transport layer equivalent to + regular TCP. + +9. Acknowledgments + + The authors sincerely thank the following people for their helpful + comments and reviews of the document: Philip Eardley, Lavkesh + Lahngir, John Leslie, Costin Raiciu, Michael Tuexen, and Javier + Ubillos. + + + +Scharf & Ford Informational [Page 23] + +RFC 6897 MPTCP API March 2013 + + + 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. + +10. References + +10.1. Normative References + + [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, + September 1981. + + [2] Braden, R., "Requirements for Internet Hosts - Communication + Layers", STD 3, RFC 1122, October 1989. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, + "Architectural Guidelines for Multipath TCP Development", + RFC 6182, March 2011. + + [5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP + Extensions for Multipath Operation with Multiple Addresses", + RFC 6824, January 2013. + + [6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath + Operation with Multiple Addresses", RFC 6181, March 2011. + + [7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion + Control for Multipath Transport Protocols", RFC 6356, + October 2011. + + [8] "IEEE Standard for Information Technology -- Portable Operating + System Interface (POSIX) Base Specifications, Issue 7", IEEE + Std. 1003.1-2008, 2008. + +10.2. Informative References + + [9] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced + Sockets Application Program Interface (API) for IPv6", + RFC 3542, May 2003. + + [10] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for + Mobile IPv6", RFC 4584, July 2006. + + + + +Scharf & Ford Informational [Page 24] + +RFC 6897 MPTCP API March 2013 + + + [11] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets + Application Program Interface (API) for Multihoming Shim", + RFC 6316, July 2011. + + [12] Komu, M. and T. Henderson, "Basic Socket Interface Extensions + for the Host Identity Protocol (HIP)", RFC 6317, July 2011. + + [13] 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. + + [14] Blanchet, M. and P. Seite, "Multiple Interfaces and + Provisioning Domains Problem Statement", RFC 6418, + November 2011. + + [15] Wasserman, M. and P. Seite, "Current Practices for Multiple- + Interface Hosts", RFC 6419, November 2011. + + [16] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with + Dual-Stack Hosts", RFC 6555, April 2012. + + [17] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) + Protocol Version 1.2", RFC 5246, August 2008. + + [18] 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. + + [19] 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. + + [20] Sarolahti, P., "Multi-address Interface in the Socket API", + Work in Progress, March 2010. + + [21] Khalili, R., Gast, N., Popovic, M., and J. Le Boudec, + "Performance Issues with MPTCP", Work in Progress, + February 2013. + + [22] 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. + + + + + + +Scharf & Ford Informational [Page 25] + +RFC 6897 MPTCP API March 2013 + + +Appendix A. Requirements on a Future Advanced MPTCP API + +A.1. Design Considerations + + Multipath transport results in many degrees of freedom. The basic + MPTCP API only defines a minimum set of the API extensions for the + interface between the MPTCP layer and applications, which does not + offer much control of the MPTCP implementation's behavior. A future, + advanced API could address further features of MPTCP and provide more + control. + + Applications that use TCP may have different requirements on the + transport layer. While developers have become used to the + characteristics of regular TCP, new opportunities created by MPTCP + could allow the service provided to be optimized further. An + advanced API could enable MPTCP-aware applications to specify + preferences and control certain aspects of the behavior, in addition + to the simple control provided by the basic interface. An advanced + API could also address aspects that are completely out of scope of + the basic API, for example, the question of whether a receiving + application could influence the sending policy. A better integration + with TLS could be another relevant objective (cf. 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 [20] 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. + + + + + + + + + + +Scharf & Ford Informational [Page 26] + +RFC 6897 MPTCP API March 2013 + + +A.2. MPTCP Usage Scenarios and Application Requirements + + There are different MPTCP usage scenarios. An application that + wishes to transmit bulk data will want MPTCP to provide a high- + throughput service immediately, through creating and maximizing + utilization of all available subflows. This is the default MPTCP use + case. + + But at the other extreme, there are applications that are highly + interactive but require only a small amount of throughput, and these + are optimally served by low latency and jitter stability. In such a + situation, it would be preferable for the traffic to use only the + lowest-latency subflow (assuming it has sufficient capacity), maybe + with one or two additional subflows for resilience and recovery + purposes. The key challenge for such a strategy is that the delay on + a path may fluctuate significantly and that just always selecting the + path with the smallest delay might result in instability. + + The choice between bulk data transport and latency-sensitive + transport affects the scheduler in terms of whether traffic should + be, by default, sent on one subflow or across several subflows. Even + if the total bandwidth required is less than that available on an + individual path, it is desirable to spread this load to reduce stress + on potential bottlenecks, and this is why this method should be the + default for bulk data transport. However, that may not be optimal + for applications that require latency/jitter stability. + + In the case of the latter option, a further question arises: Should + additional subflows be used whenever the primary subflow is + overloaded, or only when the primary path fails (hot standby)? In + other words, is latency stability or bandwidth more important to the + application? This results in two different options: Firstly, there + is the single path that can overflow into an additional subflow; and + secondly, there is the single path with hot standby, whereby an + application may want an alternative backup subflow in order to + improve resilience. In case data delivery on the first subflow + fails, the data transport could immediately be continued on the + second subflow, which is idle otherwise. + + Yet another complication is introduced with the potential that MPTCP + introduces for changes in available bandwidth as the number of + available subflows changes. Such jitter in bandwidth may prove + confusing for some applications, such as video or audio streaming, + that dynamically adapt codecs based on available bandwidth. Such + applications may prefer MPTCP to attempt to provide a consistent + bandwidth as far as is possible and avoid maximizing the use of all + subflows. + + + + +Scharf & Ford Informational [Page 27] + +RFC 6897 MPTCP API March 2013 + + + 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. + + + + + + + +Scharf & Ford Informational [Page 28] + +RFC 6897 MPTCP API March 2013 + + +A.3. Potential Requirements on an Advanced MPTCP API + + The following is a list of potential requirements for an advanced + MPTCP API beyond the features of the basic API. It is included here + for information only: + + REQ5: An application should be able to establish MPTCP connections + without using IP addresses as locators. + + REQ6: An application should be able to obtain usage information and + statistics about all subflows (e.g., ratio of traffic sent + via this subflow). + + REQ7: An application should be able to request a change in the + number of subflows in use, thus triggering removal or + addition of subflows. An even finer control granularity + would be a request for the establishment of a specific + subflow to a provided destination or a request for the + termination of a specified, existing subflow. + + REQ8: An application should be able to inform the MPTCP + implementation about its high-level performance requirements, + e.g., in the form of a profile. + + REQ9: An application should be able to indicate communication + characteristics, e.g., the expected amount of data to be + sent, the expected duration of the connection, or the + expected rate at which data is provided. Applications may in + some cases be able to forecast such properties. If so, such + information could be an additional input parameter for + heuristics inside the MPTCP implementation, which could be + useful, for example, to decide when to set up additional + subflows. + + REQ10: An application should be able to control the automatic + establishment/termination of subflows. This would imply a + selection among different heuristics of the path manager, + e.g., 'try as soon as possible', 'wait until there is a bunch + of data', etc. + + REQ11: An application should be able to set preferred subflows or + subflow usage policies. This would result in a selection + among different configurations of the multipath scheduler. + For instance, an application might want to use certain + subflows as backup only. + + + + + + +Scharf & Ford Informational [Page 29] + +RFC 6897 MPTCP API March 2013 + + + 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. + +A.4. Integration with the SCTP Sockets API + + The advanced API may also integrate or use the SCTP sockets API. The + following functions that are defined for SCTP have functionality + similar to the basic MPTCP API: + + o sctp_bindx() + + o sctp_connectx() + + o sctp_getladdrs() + + o sctp_getpaddrs() + + o sctp_freeladdrs() + + o sctp_freepaddrs() + + The syntax and semantics of these functions are described in [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. + + + +Scharf & Ford Informational [Page 30] + +RFC 6897 MPTCP API March 2013 + + +Authors' Addresses + + Michael Scharf + Alcatel-Lucent Bell Labs + Lorenzstrasse 10 + 70435 Stuttgart + Germany + + EMail: michael.scharf@alcatel-lucent.com + + + Alan Ford + Cisco + Ruscombe Business Park + Ruscombe, Berkshire RG10 9NN + UK + + EMail: alanford@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Scharf & Ford Informational [Page 31] + |