MPTCP Working Group B. Hesmans Internet-Draft O. Bonaventure Intended status: Informational F. Duchene Expires: September 6, 2018 UCLouvain March 05, 2018 A socket API to control Multipath TCP draft-hesmans-mptcp-socket-03 Abstract This document proposes an enhanced socket API to allow applications to control the operation of a Multipath TCP stack. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2018. Copyright Notice Copyright (c) 2018 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. Hesmans, et al. Expires September 6, 2018 [Page 1] Internet-Draft MPTCP API March 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 4 3. Multipath TCP Socket API . . . . . . . . . . . . . . . . . . 5 3.1. Subflow list . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Open subflow . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Close subflow . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Get subflow tuple . . . . . . . . . . . . . . . . . . . . 9 3.5. Subflow socket option . . . . . . . . . . . . . . . . . . 10 3.6. IPv6 Segment Routing extension . . . . . . . . . . . . . 11 4. Multipath-TCP events . . . . . . . . . . . . . . . . . . . . 13 4.1. Subflow creation . . . . . . . . . . . . . . . . . . . . 14 4.2. Subflow deletion . . . . . . . . . . . . . . . . . . . . 14 4.3. New local address available . . . . . . . . . . . . . . . 14 4.4. New remote address available . . . . . . . . . . . . . . 14 4.5. Prio changed . . . . . . . . . . . . . . . . . . . . . . 14 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security considerations . . . . . . . . . . . . . . . . . . . 14 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Multipath TCP [RFC6824] was designed as an incrementally deployable [RFC6182] extension to TCP [RFC0793]. One of its design objectives was to remain backward compatible with the traditional socket API to enable applications to benefit from Multipath TCP without requiring any modification. This solution has been adopted by the Multipath TCP implementation in the Linux kernel [MultipathTCP-Linux]. In this implementation, once Multipath TCP has been enabled, all TCP applications automatically use it. It is possible to turn Multipath TCP off on a per socket basis, but this is rarely used. The Multipath TCP stack contains a module, called the path manager, that controls the utilisation of the different paths. Three path managers have been implemented : o the "full mesh" path manager, which is the default one, tries to create subflows in full mesh among all the client addresses and all addresses advertised by the server. All subflows are created by the client because the server assumes that the client is often behind a NAT or firewall Hesmans, et al. Expires September 6, 2018 [Page 2] Internet-Draft MPTCP API March 2018 o the "ndiffports" path manager was designed for single-homed hosts. It creates n parallel subflows between the client and the server. It has been defined notably for datacenters [SIGCOMM11] o the "user space" path manager [CONEXT15] uses Netlink to expose events to specific applications and enables them to control the operation of the underlying MPTCP stack. However, discussions with users of the Multipath TCP implementation in the Linux kernel indicate that they would often want a finer control on the underlying stack and more precisely on the utilisation of the different subflows. Smartphone applications are a typical example. Measurements indicate that with the default path manager, there are many subflows that are created without being used [PAM2016] [COMMAG2016]. This increases energy consumption and could be avoided on Multipath-TCP aware applications. The Multipath TCP implementation used in Apple smartphones, tablets and laptops [Apple-MPTCP] took a different approach. This MPTCP stack is not exposed by default to the applications. To use MPTCP, they need to use a specific address family and special system calls [ANRW2016]. Using a new address family and new system calls is a major modification and application developers may not agree to maintain different versions of their applications that run above regular TCP and Multipath TCP. In this document, we propose a simple but powerful API that relies only on socket options and the existing system calls to interact with the MPTCP stack. Application developers are already used to manipulate socket options and could thus easily extend their applications to better utilize the underlying MPTCP stack when available. This approach is similar to the API outlined in [RFC6897], but to our knowledge, this API has never been implemented. We also note that during the last decade the socket API exposed by SCTP evolved to use more socket options [RFC6458]. This document is organised as follows. We first describe the basic operation of our enhanced API in section Section 2. We then show in section Section 3 how the "getsockopt" and "setsockopt" system calls can be used to control the underlying Multipath TCP stack. We focus on basic operations like retrieving the list of subflows that compose a Multipath TCP connection, establishing a new subflow or terminating an existing subflow in this first version of the document. We will address in the next revision of this document more advanced topics such as non-blocking I/O and the utilisation of the "recvmsg" and "sendmsg" system calls. Hesmans, et al. Expires September 6, 2018 [Page 3] Internet-Draft MPTCP API March 2018 2. Basic operation In this section, we briefly describe the basic utilisation of the enhanced socket API for Multipath TCP. As an illustration, we consider a dual-homed smartphone having a WiFi and a cellular interface that interacts with a single homed server. We assume for simplicity in this example that the server is passive. It creates a listening socket and accepts incoming connections through the following system calls : o "socket()" o "bind()" o "listen()" Then data can be sent (resp. received) with the "send()" (resp. "recv()") system calls and the connection can be terminated by using the "close()" or "shutdown()" system calls. On the client side, the following system calls are used to create a Multipath TCP connection : o "socket()" o "connect()" The "connect()" system call succeeds once the initial subflow of the Multipath TCP connection has been established. We assume here that Multipath TCP has been negotiated successfully. The client can then send and receive data by using the "send()" and "recv()" system calls. The enhanced socket API enables the client (and also the server since the protocol is symmetrical, but we ignore this in this section) to control the utilisation of the different subflows. This control is performed by setting and retrieving socket options through the "setsockopt()" and "getsockopt()" system calls. Four main socket options are defined to control the subflows used by the underlying Multipath TCP connection : o "MPTCP_GET_SUB_IDS" can only be used by "getsockopt()". It is used to retrieve the current list of the subflows that compose the underlying Multipath TCP connection. In this list, each one identifier is associated with each subflow. Hesmans, et al. Expires September 6, 2018 [Page 4] Internet-Draft MPTCP API March 2018 o "MPTCP_GET_SUB_TUPLE". This socket option is equivalent to the "getpeername()" system call with regular TCP, but on a per subflow basis. When used with "getsockopt()", it allows to retrieve the IP addresses and ports of the two endpoints of a particular subflow. o "MPTCP_OPEN_SUB_TUPLE". This socket option is the equivalent to the "connect()" system call, but it operates on subflows. It allows to attempt to establish a new subflow by specifying its (remote and optionally local) endpoints. o "MPTCP_CLOSE_SUB_ID". This socket option allows to close a specific subflow. As an example, consider a smartphone application that creates a Multipath TCP connection. This connection is established by using the "connect()" system call. The MPTCP stack selects the outgoing interface based on its routing table. Let us assume that the initial subflow is established over the cellular interface. This is the only subflow used for this connection at this time. To perform a handover, the smartphone application would use "MPTCP_OPEN_SUB_TUPLE" to create a new subflow over the WiFi interface. It can then use "MPTCP_GET_SUB_TUPLE" to retrieve the local and remote addresses of this subflow. Now that the WiFi subflow is active, the application can use "MPTCP_CLOSE_SUB_ID" to close the cellular subflow. 3. Multipath TCP Socket API From an application viewpoint, the interaction with the underlying stack is awlays performed through a single socket. This unique socket is used even if a Multipath TCP stack is used and many subflows have been established. This single socket abstraction is important because the applications exchange data through a bytestream with both TCP and Multipath TCP. We preserve this abstraction in the proposed enhanced socket API but expose some details of the underlying MPTCP stack to the application. For all the socket options presented bellow, we assume that the underlying Multipath TCP connection is still a Multipath TCP connection. Otherwise (e.g. after a fallback), they return an error and set errno to "EOPNOTSUPP" is returned. 3.1. Subflow list The first important information that a stack can expose are the different subflows that are combined within a given Multipath TCP connection. For this, we need a data structure that represents the different subflows that compose a connection. The "mptcp_sub_ids" Hesmans, et al. Expires September 6, 2018 [Page 5] Internet-Draft MPTCP API March 2018 structure shown in figure Figure 1 contains an array with the status of the different subflows that compose a given connection. The actual size of the array depends on the number of subflows and is defined with the "sub_count" field. The "mptcp_sub_status" structure reflects the status of each subflow. A subflow is identified by its "id". In addition to the "id" of the subflow, the "mptcp_sub_status" structure contains one flag : the "low\_prio" flag. It is set to 1 when the subflow is defined as a back-up subflow. Other flags could be exposed through this structure in the future. struct mptcp_sub_status { __u8 id; __u16 low_prio:1; }; struct mptcp_sub_ids { __u8 sub_count; struct mptcp_sub_status sub_status[]; }; Figure 1: The mptcp_sub_ids and mptcp_sub_status structures This structure is used by the "MPTCP_GET_SUB_IDS" socket option. More precisely, the "getsockopt", when used with the "MPTCP_GET_SUB_IDS" socket option can retrieve the "mptcp_sub_ids" of the underlying Multipath TCP connection. This call may return an empty array if the connection does not contain any subflow. This can happen with Multipath TCP when the last subflow composing the connection has been terminated abruptly. The "id" that is returned in the "mptcp_sub_ids" structure is important because it identifies the subflow and is used as an identifier by the other socket options. The call may return the error "EINVAL" if the buffer passed by the application is too small to copy the array of subflow status. A simple example of its utilisation is presented in figure Figure 2. Hesmans, et al. Expires September 6, 2018 [Page 6] Internet-Draft MPTCP API March 2018 int i; unsigned int optlen; struct mptcp_sub_ids *ids; optlen = 42; ids = malloc(optlen); getsockopt(sockfd, IPPROTO_TCP, MPTCP_GET_SUB_IDS, ids, &optlen); for(i = 0; i < ids->sub_count; i++){ printf("Subflow id : %i\n", ids->sub_status[i].id); } Figure 2: Sample code for the utilisation of MPTCP_GET_SUB_IDS 3.2. Open subflow Another important part of the API is to enable an application to open new subflows. This is possible through the "MPTCP_OPEN_SUB_TUPLE" socket option. This option uses the "mptcp_sub_tuple" structure shown in figure Figure 3 to pass the priority, local and remote endpoints of the new subflow. struct mptcp_sub_tuple { __u8 id; __u8 prio; __u8 addrs[0]; int if_idx; }; Figure 3: The mptcp_sub_tuple structure The "id" field is an output. This is the "id" of the created subflow. The "prio" field indicates if the new subflow should be considered as back-up or not. The "addrs" must be a pair array of size two. The first address must be the address of the source and the second address must be the address of the destination. The actual structure passed must be either "sockaddr_in" or "sockaddr_in6", but the two elements of the array must be of the same type. The struct "sockaddr" can be used to determine which one is actually passed. The caller can also set the source address to be either "INADDR_ANY" for IPv4 or "in6addr_any" for IPv6. In this case, the kernel chooses the source address to be used for the new subflow. Hesmans, et al. Expires September 6, 2018 [Page 7] Internet-Draft MPTCP API March 2018 If a single source address is used for multiple interfaces, the caller may choose the interface to be used by setting the "if_idx" field. If this field is set to zero the kernel will choose the default interface. Errors returned by either "bind()" or "connect()" are returned if an error occurred during the process. An example is provided in figure Figure 4. unsigned int optlen; struct mptcp_sub_tuple *sub_tuple; struct sockaddr_in *addr; int error; optlen = sizeof(struct mptcp_sub_tuple) + 2 * sizeof(struct sockaddr_in); sub_tuple = malloc(optlen); sub_tuple->id = 0; sub_tuple->prio = 0; addr = (struct sockaddr_in*) &sub_tuple->addrs[0]; addr->sin_family = AF_INET; addr->sin_port = htons(12345); inet_pton(AF_INET, "10.0.0.1", &addr->sin_addr); addr++; addr->sin_family = AF_INET; addr->sin_port = htons(1234); inet_pton(AF_INET, "10.1.0.1", &addr->sin_addr); error = getsockopt(sockfd, IPPROTO_TCP, MPTCP_OPEN_SUB_TUPLE, sub_tuple, &optlen); Figure 4: Sample code to establish an additional subflow 3.3. Close subflow To close a subflow, the socket option "MPTCP_CLOSE_SUBFLOW" is used. This option used the "mptcp_close_sub_id" structure defined in figure Figure 5. Hesmans, et al. Expires September 6, 2018 [Page 8] Internet-Draft MPTCP API March 2018 struct mptcp_close_sub_id { __u8 id; int how; }; Figure 5: The mptcp_close_sub_id structure In the above structure, "id" is the identifier of the subflow that needs to be closed. If the "id" is invalid, "EINVAL" is returned. The "how" field is used to define how to subflow should be terminated. It recognises the same set of constant that are used by "shutdown()". In addition to this set, "RST" can be used to indicates that the subflow should be terminated by sending an "RST". 3.4. Get subflow tuple An application may also be interested by the addresses and ports that are used by a given subflow. To retrieve this information, the socket option "MPTCP_GET_SUB_TUPLE" is used in combination with the "mptcp_sub_tuple" structure shown in figure Figure 6. struct mptcp_sub_tuple { __u8 id; __u8 addrs[0]; }; Figure 6: The mptcp_sub_tuple structure This is the same structure as the one used to open a subflow but in this context, "id" is the input and "addrs" is the output. A sample code is provided in figure Figure 7. Hesmans, et al. Expires September 6, 2018 [Page 9] Internet-Draft MPTCP API March 2018 unsigned int optlen; struct mptcp_sub_tuple *sub_tuple; optlen = 100; sub_tuple = malloc(optlen); sub_tuple->id = sub_id; getsockopt(sockfd, IPPROTO_TCP, MPTCP_GET_SUB_TUPLE, sub_tuple, &optlen); sin = (struct sockaddr_in*) &sub_tuple->addrs[0]; printf("\tip src : %s src port : %hu\n", inet_ntoa(sin->sin_addr), ntohs(sin->sin_port)); sin++; printf("\tip dst : %s dst port : %hu\n", inet_ntoa(sin->sin_addr), ntohs(sin->sin_port)); Figure 7: Sample code using the MPTCP_GET_SUB_TUPLE option 3.5. Subflow socket option TCP/IP implementations support different socket options. Some of them can be applied to the TCP layer while others can be applied to the IP layer. To be able to issue a socket option on a specific subflow, we define the "MPTCP_SUB_GETSOCKOPT" and "MPTCP_SUB_SETSOCKOPT" options. These two socket options use respectively the structures presented in figure Figure 8. Hesmans, et al. Expires September 6, 2018 [Page 10] Internet-Draft MPTCP API March 2018 struct mptcp_sub_getsockopt { __u8 id; int level; int optname; char __user *optval; unsigned int __user *optlen; }; struct mptcp_sub_setsockopt { __u8 id; int level; int optname; char __user *optval; unsigned int optlen; }; Figure 8: Structures used by the ``MPTCP_SUB_GETSOCKOPT`` and ``MPTCP_SUB_SETSOCKOPT`` options In the two structures "id" indicates to which subflow the socket option should be redirected. The end of each structure contains the information needed to perform the socket option call on the subflow. Figure Figure 9 illustrates how the IP_TSO socket option can be applied on a particular subflow. unsigned int optlen, sub_optlen; struct mptcp_sub_setsockopt sub_sso; int val = 12; optlen = sizeof(struct mptcp_sub_setsockopt); sub_optlen = sizeof(int); sub_sso.id = sub_id; sub_sso.level = IPPROTO_IP; sub_sso.optname = IP_TOS; sub_sso.optlen = sub_optlen; sub_sso.optval = (char *) &val; setsockopt(sockfd, IPPROTO_TCP, MPTCP_SUB_SETSOCKOPT, &sub_sso, optlen); Figure 9: Example socket option 3.6. IPv6 Segment Routing extension Segment Routing (SR) [I-D.ietf-spring-segment-routing] allows a node to steer packets through specific paths inside a network. The IPv6 dataplane relies on the IPv6 Segment Routing Header which can be Hesmans, et al. Expires September 6, 2018 [Page 11] Internet-Draft MPTCP API March 2018 added to IPv6 packets [I-D.ietf-6man-segment-routing-header]. Multipath-TCP can leverage SRv6 to establish subflows that use a specific path. Various use case are possible, including disjoint paths or traffic engineered paths. To support IPv6 Segment routing, the Segment Routing Header (SRH) needs to be associated to a subflow. The modified structure is presented in figure Figure 10. struct mptcp_sub_tuple { __u8 id; __u8 prio; __u8 addrs[0]; int if_idx; struct ipv6_sr_hdr *ipv6_srh; }; Figure 10: The SRv6 enabled mptcp_sub_tuple structure With this modified structure, the SRH can now be associated to a subflow. An example is provided in figure Figure 11. In this figure, a subflow is established between 2001:DB8:1111::1 and 2001:DB8:3333::1 passing through 2001:DB8:2222::1. /* SRH structure */ struct ipv6_sr_hdr { uint8_t nexthdr; uint8_t hdrlen; uint8_t type; uint8_t segments_left; uint8_t first_segment; uint8_t flags; uint16_t reserved; struct in6_addr segments[0]; }; unsigned int optlen; struct mptcp_sub_tuple *sub_tuple; struct sockaddr_in6 *addr; int srh_len, error; struct ipv6_sr_hdr *srh; optlen = sizeof(struct mptcp_sub_tuple) + 2 * sizeof(struct sockaddr_in6); sub_tuple = malloc(optlen); sub_tuple->id = 0; sub_tuple->prio = 0; Hesmans, et al. Expires September 6, 2018 [Page 12] Internet-Draft MPTCP API March 2018 addr = (struct sockaddr_in6*) &sub_tuple->addrs[0]; addr->sin_family = AF_INET6; addr->sin_port = htons(12345); inet_pton(AF_INET6, "2001:DB8:1111::1", &addr->sin_addr); addr++; addr->sin_family = AF_INET6; addr->sin_port = htons(1234); inet_pton(AF_INET6, "2001:DB8:3333:1:", &addr->sin_addr); /* Now configuring the SRH to make the subflow go through 2001:DB8:2222::1 */ srh_len = sizeof(*srh) + 2 * sizeof(struct in6_addr); srh = malloc(srh_len); if (!srh) return -1; srh->nexthdr = 0; srh->hdrlen = 4; srh->type = 4; srh->segments_left = 1; srh->first_segment = 1; srh->flags = 0; srh->reserved = 0; memset(&srh->segments[0], 0, sizeof(struct in6_addr)); inet_pton(AF_INET6, "2001:DB8:2222::1", &srh->segments[1]); sub_tuple->ipv6_srh = srh; error = getsockopt(sockfd, IPPROTO_TCP, MPTCP_OPEN_SUB_TUPLE, sub_tuple, &optlen); Figure 11: Sample code to establish an additional subflow with an SRH The socket API for IPv6 Segment Routing is described in [SRv6Sockets]. 4. Multipath-TCP events In some cases, Multipath-TCP connections should be able to react upon events. Applications that are aware of Multipath-TCP must receive those events in order to take their decisions and react if needed. The list of events that could be produced by Multipath-TCP stack, upon subscription to those events, are presented bellow. Hesmans, et al. Expires September 6, 2018 [Page 13] Internet-Draft MPTCP API March 2018 _** This section is still an early draft and will be updated to add more details. **_ 4.1. Subflow creation If the stack or the user requests a new subflow, the user will receive this event if the subflow has been fully established and is available to send new data. The event should contain the identification of the subflow. 4.2. Subflow deletion If one of the subflow is deleted, an event that contain the identification of the subflow must be triggered. Moreover, the reason of the deletion must be stated. 4.3. New local address available When a new local address is available, the application should receive all the informations needed to use the new address. 4.4. New remote address available See previous section. 4.5. Prio changed When one of the subflow receives a change in prio. The event must contain the identification of the subflow and the new prio. 5. IANA considerations There are no IANA considerations in this document. 6. Security considerations TCP and UDP implementations usually reserve port numbers below 1024 for privileged users. On such implementations, Multipath TCP should restrict the ability of the users to create subflows on privileged ports through the "MPTCP_OPEN_SUB_TUPLE". For similar reasons, the "MPTCP_SUB_SETSOCKOPT" socket option should not enable an unprivileged user to retrieve or modify a socket option on a subflow if he is not allowed to perform such actions on a regular TCP connection. Applications requiring strong security should implement cryptographic protocols such as TLS [RFC5246] or ssh [RFC4251]. The proposed API Hesmans, et al. Expires September 6, 2018 [Page 14] Internet-Draft MPTCP API March 2018 enables such application to better control their utilisation of the underlying interfaces by managing the different subflows. 7. Conclusion In this document, we have documented an enhanced socket API that enables applications to control the creation and the release of subflows by the underlying Multipath TCP stack. We expect that a standardised API supported by different implementations will be an important stop for the deployment of Multipath TCP aware applications on both multihomed hosts such as smartphones as well as on servers. This enhanced API has already been implemented on the Multipath TCP implementation in the Linux kernel. Future versions of this document will address more advanced utilisations of the socket API such as non-blocking I/O and the "sendmsg()" and "recvmsg()" system calls. 8. Acknowledgements We would like to thank Christoph Paasch, Quentin De Coninck Rao Shoaib for their comments on an early version of this document. 9. References 9.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . 9.2. Informative References [ANRW2016] Hesmans, B. and O. Bonaventure, "An enhanced socket API for Multipath TCP", 2016, . [Apple-MPTCP] Apple, Inc, ., "iOS - Multipath TCP Support in iOS 7", n.d., . Hesmans, et al. Expires September 6, 2018 [Page 15] Internet-Draft MPTCP API March 2018 [COMMAG2016] De Coninck, Q., Baerts, M., Hesmans, B., and O. Bonaventure, "Observing Real Smartphone Applications over Multipath TCP", IEEE Communications Magazine , March 2016, . [CONEXT15] Hesmans, B., Detal, G., Barre, S., Bauduin, R., and O. Bonaventure, "SMAPP - Towards Smart Multipath TCP-enabled APPlications", Proc. Conext 2015, Heidelberg, Germany , December 2015, . [I-D.ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., Field, B., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-08 (work in progress), January 2018. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [MultipathTCP-Linux] Paasch, C., Barre, S., and . et al, "Multipath TCP implementation in the Linux kernel", n.d., . [PAM2016] De Coninck, Q., Baerts, M., Hesmans, B., and O. Bonaventure, "A First Analysis of Multipath TCP on Smartphones", 17th International Passive and Active Measurements Conference (PAM2016) , March 2016, . [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, . Hesmans, et al. Expires September 6, 2018 [Page 16] Internet-Draft MPTCP API March 2018 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, . [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, . [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, . [SIGCOMM11] Raiciu, C., Barre, S., Pluntke, C., Greenhalgh, A., Wischik, D., and M. Handley, "Improving datacenter performance and robustness with multipath TCP", Proceedings of the ACM SIGCOMM 2011 conference , 2011, . [SRv6Sockets] Duchene, F. and O. Bonaventure, "A socket API to control IPv6 Segment Routing", n.d., . Authors' Addresses Benjamin Hesmans UCLouvain Email: Benjamin.Hesmans@uclouvain.be Olivier Bonaventure UCLouvain Email: Olivier.Bonaventure@uclouvain.be Hesmans, et al. Expires September 6, 2018 [Page 17] Internet-Draft MPTCP API March 2018 Fabien Duchene UCLouvain Email: Fabien.Duchene@uclouvain.be Hesmans, et al. Expires September 6, 2018 [Page 18]