idnits 2.17.1 draft-hesmans-mptcp-socket-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 446 has weird spacing: '...ned int opt...' -- The document date (July 03, 2017) is 2482 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 412 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP Working Group B. Hesmans 3 Internet-Draft O. Bonaventure 4 Intended status: Informational UCLouvain 5 Expires: January 4, 2018 July 03, 2017 7 A socket API to control Multipath TCP 8 draft-hesmans-mptcp-socket-02 10 Abstract 12 This document proposes an enhanced socket API to allow applications 13 to control the operation of a Multipath TCP stack. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 4, 2018. 32 Copyright Notice 34 Copyright (c) 2017 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Multipath TCP Socket API . . . . . . . . . . . . . . . . . . 5 52 3.1. Subflow list . . . . . . . . . . . . . . . . . . . . . . 5 53 3.2. Open subflow . . . . . . . . . . . . . . . . . . . . . . 7 54 3.3. Close subflow . . . . . . . . . . . . . . . . . . . . . . 8 55 3.4. Get subflow tuple . . . . . . . . . . . . . . . . . . . . 9 56 3.5. Subflow socket option . . . . . . . . . . . . . . . . . . 10 57 4. Multipath-TCP events . . . . . . . . . . . . . . . . . . . . 11 58 4.1. Subflow creation . . . . . . . . . . . . . . . . . . . . 12 59 4.2. Subflow deletion . . . . . . . . . . . . . . . . . . . . 12 60 4.3. New local address available . . . . . . . . . . . . . . . 12 61 4.4. New remote address available . . . . . . . . . . . . . . 12 62 4.5. Prio changed . . . . . . . . . . . . . . . . . . . . . . 12 63 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 64 6. Security considerations . . . . . . . . . . . . . . . . . . . 12 65 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 69 9.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 Multipath TCP [RFC6824] was designed as an incrementally deployable 75 [RFC6182] extension to TCP [RFC0793]. One of its design objectives 76 was to remain backward compatible with the traditional socket API to 77 enable applications to benefit from Multipath TCP without requiring 78 any modification. This solution has been adopted by the Multipath 79 TCP implementation in the Linux kernel [MultipathTCP-Linux]. In this 80 implementation, once Multipath TCP has been enabled, all TCP 81 applications automatically use it. It is possible to turn Multipath 82 TCP off on a per socket basis, but this is rarely used. The 83 Multipath TCP stack contains a module, called the path manager, that 84 controls the utilisation of the different paths. Three path managers 85 have been implemented : 87 o the "full mesh" path manager, which is the default one, tries to 88 create subflows in full mesh among all the client addresses and 89 all addresses advertised by the server. All subflows are created 90 by the client because the server assumes that the client is often 91 behind a NAT or firewall 93 o the "ndiffports" path manager was designed for single-homed hosts. 94 It creates n parallel subflows between the client and the server. 95 It has been defined notably for datacenters [SIGCOMM11] 97 o the "user space" path manager [CONEXT15] uses Netlink to expose 98 events to specific applications and enables them to control the 99 operation of the underlying MPTCP stack. 101 However, discussions with users of the Multipath TCP implementation 102 in the Linux kernel indicate that they would often want a finer 103 control on the underlying stack and more precisely on the utilisation 104 of the different subflows. Smartphone applications are a typical 105 example. Measurements indicate that with the default path manager, 106 there are many subflows that are created without being used [PAM2016] 107 [COMMAG2016]. This increases energy consumption and could be avoided 108 on Multipath-TCP aware applications. 110 The Multipath TCP implementation used in Apple smartphones, tablets 111 and laptops [Apple-MPTCP] took a different approach. This MPTCP 112 stack is not exposed by default to the applications. To use MPTCP, 113 they need to use a specific address family and special system calls 114 [ANRW2016]. 116 Using a new address family and new system calls is a major 117 modification and application developers may not agree to maintain 118 different versions of their applications that run above regular TCP 119 and Multipath TCP. In this document, we propose a simple but 120 powerful API that relies only on socket options and the existing 121 system calls to interact with the MPTCP stack. Application 122 developers are already used to manipulate socket options and could 123 thus easily extend their applications to better utilize the 124 underlying MPTCP stack when available. This approach is similar to 125 the API outlined in [RFC6897], but to our knowledge, this API has 126 never been implemented. We also note that during the last decade the 127 socket API exposed by SCTP evolved to use more socket options 128 [RFC6458]. 130 This document is organised as follows. We first describe the basic 131 operation of our enhanced API in section Section 2. We then show in 132 section Section 3 how the "getsockopt" and "setsockopt" system calls 133 can be used to control the underlying Multipath TCP stack. We focus 134 on basic operations like retrieving the list of subflows that compose 135 a Multipath TCP connection, establishing a new subflow or terminating 136 an existing subflow in this first version of the document. We will 137 address in the next revision of this document more advanced topics 138 such as non-blocking I/O and the utilisation of the "recvmsg" and 139 "sendmsg" system calls. 141 2. Basic operation 143 In this section, we briefly describe the basic utilisation of the 144 enhanced socket API for Multipath TCP. As an illustration, we 145 consider a dual-homed smartphone having a WiFi and a cellular 146 interface that interacts with a single homed server. 148 We assume for simplicity in this example that the server is passive. 149 It creates a listening socket and accepts incoming connections 150 through the following system calls : 152 o "socket()" 154 o "bind()" 156 o "listen()" 158 Then data can be sent (resp. received) with the "send()" (resp. 159 "recv()") system calls and the connection can be terminated by using 160 the "close()" or "shutdown()" system calls. 162 On the client side, the following system calls are used to create a 163 Multipath TCP connection : 165 o "socket()" 167 o "connect()" 169 The "connect()" system call succeeds once the initial subflow of the 170 Multipath TCP connection has been established. We assume here that 171 Multipath TCP has been negotiated successfully. The client can then 172 send and receive data by using the "send()" and "recv()" system 173 calls. 175 The enhanced socket API enables the client (and also the server since 176 the protocol is symmetrical, but we ignore this in this section) to 177 control the utilisation of the different subflows. This control is 178 performed by setting and retrieving socket options through the 179 "setsockopt()" and "getsockopt()" system calls. Four main socket 180 options are defined to control the subflows used by the underlying 181 Multipath TCP connection : 183 o "MPTCP_GET_SUB_IDS" can only be used by "getsockopt()". It is 184 used to retrieve the current list of the subflows that compose the 185 underlying Multipath TCP connection. In this list, each one 186 identifier is associated with each subflow. 188 o "MPTCP_GET_SUB_TUPLE". This socket option is equivalent to the 189 "getpeername()" system call with regular TCP, but on a per subflow 190 basis. When used with "getsockopt()", it allows to retrieve the 191 IP addresses and ports of the two endpoints of a particular 192 subflow. 194 o "MPTCP_OPEN_SUB_TUPLE". This socket option is the equivalent to 195 the "connect()" system call, but it operates on subflows. It 196 allows to attempt to establish a new subflow by specifying its 197 (remote and optionally local) endpoints. 199 o "MPTCP_CLOSE_SUB_ID". This socket option allows to close a 200 specific subflow. 202 As an example, consider a smartphone application that creates a 203 Multipath TCP connection. This connection is established by using 204 the "connect()" system call. The MPTCP stack selects the outgoing 205 interface based on its routing table. Let us assume that the initial 206 subflow is established over the cellular interface. This is the only 207 subflow used for this connection at this time. To perform a 208 handover, the smartphone application would use "MPTCP_OPEN_SUB_TUPLE" 209 to create a new subflow over the WiFi interface. It can then use 210 "MPTCP_GET_SUB_TUPLE" to retrieve the local and remote addresses of 211 this subflow. Now that the WiFi subflow is active, the application 212 can use "MPTCP_CLOSE_SUB_ID" to close the cellular subflow. 214 3. Multipath TCP Socket API 216 From an application viewpoint, the interaction with the underlying 217 stack is awlays performed through a single socket. This unique 218 socket is used even if a Multipath TCP stack is used and many 219 subflows have been established. This single socket abstraction is 220 important because the applications exchange data through a bytestream 221 with both TCP and Multipath TCP. We preserve this abstraction in the 222 proposed enhanced socket API but expose some details of the 223 underlying MPTCP stack to the application. 225 For all the socket options presented bellow, we assume that the 226 underlying Multipath TCP connection is still a Multipath TCP 227 connection. Otherwise (e.g. after a fallback), they return an error 228 and set errno to "EOPNOTSUPP" is returned. 230 3.1. Subflow list 232 The first important information that a stack can expose are the 233 different subflows that are combined within a given Multipath TCP 234 connection. For this, we need a data structure that represents the 235 different subflows that compose a connection. The "mptcp_sub_ids" 236 structure shown in figure Figure 1 contains an array with the status 237 of the different subflows that compose a given connection. The 238 actual size of the array depends on the number of subflows and is 239 defined with the "sub_count" field. The "mptcp_sub_status" structure 240 reflects the status of each subflow. A subflow is identified by its 241 "id". In addition to the "id" of the subflow, the "mptcp_sub_status" 242 structure contains one flag : the "low\_prio" flag. It is set to 1 243 when the subflow is defined as a back-up subflow. Other flags could 244 be exposed through this structure in the future. 246 struct mptcp_sub_status { 247 __u8 id; 248 __u16 low_prio:1; 249 }; 251 struct mptcp_sub_ids { 252 __u8 sub_count; 253 struct mptcp_sub_status sub_status[]; 254 }; 256 Figure 1: The mptcp_sub_ids and mptcp_sub_status structures 258 This structure is used by the "MPTCP_GET_SUB_IDS" socket option. 259 More precisely, the "getsockopt", when used with the 260 "MPTCP_GET_SUB_IDS" socket option can retrieve the "mptcp_sub_ids" of 261 the underlying Multipath TCP connection. This call may return an 262 empty array if the connection does not contain any subflow. This can 263 happen with Multipath TCP when the last subflow composing the 264 connection has been terminated abruptly. 266 The "id" that is returned in the "mptcp_sub_ids" structure is 267 important because it identifies the subflow and is used as an 268 identifier by the other socket options. 270 The call may return the error "EINVAL" if the buffer passed by the 271 application is too small to copy the array of subflow status. 273 A simple example of its utilisation is presented in figure Figure 2. 275 int i; 276 unsigned int optlen; 277 struct mptcp_sub_ids *ids; 279 optlen = 42; 281 ids = malloc(optlen); 283 getsockopt(sockfd, IPPROTO_TCP, MPTCP_GET_SUB_IDS, ids, &optlen); 285 for(i = 0; i < ids->sub_count; i++){ 286 printf("Subflow id : %i\n", ids->sub_status[i].id); 287 } 289 Figure 2: Sample code for the utilisation of MPTCP_GET_SUB_IDS 291 3.2. Open subflow 293 Another important part of the API is to enable an application to open 294 new subflows. This is possible through the "MPTCP_OPEN_SUB_TUPLE" 295 socket option. This option uses the "mptcp_sub_tuple" structure 296 shown in figure Figure 3 to pass the priority, local and remote 297 endpoints of the new subflow. 299 struct mptcp_sub_tuple { 300 __u8 id; 301 __u8 prio; 302 __u8 addrs[0]; 303 int if_idx; 304 }; 306 Figure 3: The mptcp_sub_tuple structure 308 The "id" field is an output. This is the "id" of the created 309 subflow. The "prio" field indicates if the new subflow should be 310 considered as back-up or not. The "addrs" must be a pair array of 311 size two. The first address must be the address of the source and 312 the second address must be the address of the destination. The 313 actual structure passed must be either "sockaddr_in" or 314 "sockaddr_in6", but the two elements of the array must be of the same 315 type. The struct "sockaddr" can be used to determine which one is 316 actually passed. 318 The caller can also set the source address to be either "INADDR_ANY" 319 for IPv4 or "in6addr_any" for IPv6. In this case, the kernel chooses 320 the source address to be used for the new subflow. 322 If a single source address is used for multiple interfaces, the 323 caller may choose the interface to be used by setting the "if_idx" 324 field. If this field is set to zero the kernel will choose the 325 default interface. 327 Errors returned by either "bind()" or "connect()" are returned if an 328 error occurred during the process. 330 An example is provided in figure Figure 4. 332 unsigned int optlen; 333 struct mptcp_sub_tuple *sub_tuple; 334 struct sockaddr_in *addr; 335 int error; 337 optlen = sizeof(struct mptcp_sub_tuple) + 338 2 * sizeof(struct sockaddr_in); 339 sub_tuple = malloc(optlen); 341 sub_tuple->id = 0; 342 sub_tuple->prio = 0; 344 addr = (struct sockaddr_in*) &sub_tuple->addrs[0]; 346 addr->sin_family = AF_INET; 347 addr->sin_port = htons(12345); 348 inet_pton(AF_INET, "10.0.0.1", &addr->sin_addr); 350 addr++; 352 addr->sin_family = AF_INET; 353 addr->sin_port = htons(1234); 354 inet_pton(AF_INET, "10.1.0.1", &addr->sin_addr); 356 error = getsockopt(sockfd, IPPROTO_TCP, MPTCP_OPEN_SUB_TUPLE, 357 sub_tuple, &optlen); 359 Figure 4: Sample code to establish an additional subflow 361 3.3. Close subflow 363 To close a subflow, the socket option "MPTCP_CLOSE_SUBFLOW" is used. 364 This option used the "mptcp_close_sub_id" structure defined in figure 365 Figure 5. 367 struct mptcp_close_sub_id { 368 __u8 id; 369 int how; 370 }; 372 Figure 5: The mptcp_close_sub_id structure 374 In the above structure, "id" is the identifier of the subflow that 375 needs to be closed. If the "id" is invalid, "EINVAL" is returned. 377 The "how" field is used to define how to subflow should be 378 terminated. It recognises the same set of constant that are used by 379 "shutdown()". In addition to this set, "RST" can be used to 380 indicates that the subflow should be terminated by sending an "RST". 382 3.4. Get subflow tuple 384 An application may also be interested by the addresses and ports that 385 are used by a given subflow. To retrieve this information, the 386 socket option "MPTCP_GET_SUB_TUPLE" is used in combination with the 387 "mptcp_sub_tuple" structure shown in figure Figure 6. 389 struct mptcp_sub_tuple { 390 __u8 id; 391 __u8 addrs[0]; 392 }; 394 Figure 6: The mptcp_sub_tuple structure 396 This is the same structure as the one used to open a subflow but in 397 this context, "id" is the input and "addrs" is the output. 399 A sample code is provided in figure Figure 7. 401 unsigned int optlen; 402 struct mptcp_sub_tuple *sub_tuple; 404 optlen = 100; 406 sub_tuple = malloc(optlen); 408 sub_tuple->id = sub_id; 409 getsockopt(sockfd, IPPROTO_TCP, MPTCP_GET_SUB_TUPLE, sub_tuple, 410 &optlen); 412 sin = (struct sockaddr_in*) &sub_tuple->addrs[0]; 414 printf("\tip src : %s src port : %hu\n", inet_ntoa(sin->sin_addr), 415 ntohs(sin->sin_port)); 417 sin++; 419 printf("\tip dst : %s dst port : %hu\n", inet_ntoa(sin->sin_addr), 420 ntohs(sin->sin_port)); 422 Figure 7: Sample code using the MPTCP_GET_SUB_TUPLE option 424 3.5. Subflow socket option 426 TCP/IP implementations support different socket options. Some of 427 them can be applied to the TCP layer while others can be applied to 428 the IP layer. To be able to issue a socket option on a specific 429 subflow, we define the "MPTCP_SUB_GETSOCKOPT" and 430 "MPTCP_SUB_SETSOCKOPT" options. These two socket options use 431 respectively the structures presented in figure Figure 8. 433 struct mptcp_sub_getsockopt { 434 __u8 id; 435 int level; 436 int optname; 437 char __user *optval; 438 unsigned int __user *optlen; 439 }; 441 struct mptcp_sub_setsockopt { 442 __u8 id; 443 int level; 444 int optname; 445 char __user *optval; 446 unsigned int optlen; 447 }; 449 Figure 8: Structures used by the ``MPTCP_SUB_GETSOCKOPT`` and 450 ``MPTCP_SUB_SETSOCKOPT`` options 452 In the two structures "id" indicates to which subflow the socket 453 option should be redirected. The end of each structure contains the 454 information needed to perform the socket option call on the subflow. 456 Figure Figure 9 illustrates how the IP_TSO socket option can be 457 applied on a particular subflow. 459 unsigned int optlen, sub_optlen; 460 struct mptcp_sub_setsockopt sub_sso; 461 int val = 12; 463 optlen = sizeof(struct mptcp_sub_setsockopt); 464 sub_optlen = sizeof(int); 465 sub_sso.id = sub_id; 466 sub_sso.level = IPPROTO_IP; 467 sub_sso.optname = IP_TOS; 468 sub_sso.optlen = sub_optlen; 469 sub_sso.optval = (char *) &val; 471 setsockopt(sockfd, IPPROTO_TCP, MPTCP_SUB_SETSOCKOPT, &sub_sso, 472 optlen); 474 Figure 9: Example socket option 476 4. Multipath-TCP events 478 In some cases, Multipath-TCP connections should be able to react upon 479 events. Applications that are aware of Multipath-TCP must receive 480 those events in order to take their decisions and react if needed. 482 The list of events that could be produced by Multipath-TCP stack, 483 upon subscription to those events, are presented bellow. 485 _** This section is still an early draft and will be updated to add 486 more details. **_ 488 4.1. Subflow creation 490 If the stack or the user requests a new subflow, the user will 491 receive this event if the subflow has been fully established and is 492 available to send new data. The event should contain the 493 identification of the subflow. 495 4.2. Subflow deletion 497 If one of the subflow is deleted, an event that contain the 498 identification of the subflow must be triggered. Moreover, the 499 reason of the deletion must be stated. 501 4.3. New local address available 503 When a new local address is available, the application should receive 504 all the informations needed to use the new address. 506 4.4. New remote address available 508 See previous section. 510 4.5. Prio changed 512 When one of the subflow receives a change in prio. The event must 513 contain the identification of the subflow and the new prio. 515 5. IANA considerations 517 There are no IANA considerations in this document. 519 6. Security considerations 521 TCP and UDP implementations usually reserve port numbers below 1024 522 for privileged users. On such implementations, Multipath TCP should 523 restrict the ability of the users to create subflows on privileged 524 ports through the "MPTCP_OPEN_SUB_TUPLE". 526 For similar reasons, the "MPTCP_SUB_SETSOCKOPT" socket option should 527 not enable an unprivileged user to retrieve or modify a socket option 528 on a subflow if he is not allowed to perform such actions on a 529 regular TCP connection. 531 Applications requiring strong security should implement cryptographic 532 protocols such as TLS [RFC5246] or ssh [RFC4251]. The proposed API 533 enables such application to better control their utilisation of the 534 underlying interfaces by managing the different subflows. 536 7. Conclusion 538 In this document, we have documented an enhanced socket API that 539 enables applications to control the creation and the release of 540 subflows by the underlying Multipath TCP stack. We expect that a 541 standardised API supported by different implementations will be an 542 important stop for the deployment of Multipath TCP aware applications 543 on both multihomed hosts such as smartphones as well as on servers. 544 This enhanced API has already been implemented on the Multipath TCP 545 implementation in the Linux kernel. Future versions of this document 546 will address more advanced utilisations of the socket API such as 547 non-blocking I/O and the "sendmsg()" and "recvmsg()" system calls. 549 8. Acknowledgements 551 We would like to thank Christoph Paasch, Quentin De Coninck Rao 552 Shoaib for their comments on an early version of this document. 554 9. References 556 9.1. Normative References 558 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 559 RFC 793, DOI 10.17487/RFC0793, September 1981, 560 . 562 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 563 "TCP Extensions for Multipath Operation with Multiple 564 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 565 . 567 9.2. Informative References 569 [ANRW2016] 570 Hesmans, B. and O. Bonaventure, "An enhanced socket API 571 for Multipath TCP", 2016, . 574 [Apple-MPTCP] 575 Apple, Inc, ., "iOS - Multipath TCP Support in iOS 7", 576 n.d., . 578 [COMMAG2016] 579 De Coninck, Q., Baerts, M., Hesmans, B., and O. 580 Bonaventure, "Observing Real Smartphone Applications over 581 Multipath TCP", IEEE Communications Magazine , March 2016, 582 . 585 [CONEXT15] 586 Hesmans, B., Detal, G., Barre, S., Bauduin, R., and O. 587 Bonaventure, "SMAPP - Towards Smart Multipath TCP-enabled 588 APPlications", Proc. Conext 2015, Heidelberg, Germany , 589 December 2015, . 592 [MultipathTCP-Linux] 593 Paasch, C., Barre, S., and . et al, "Multipath TCP 594 implementation in the Linux kernel", n.d., 595 . 597 [PAM2016] De Coninck, Q., Baerts, M., Hesmans, B., and O. 598 Bonaventure, "A First Analysis of Multipath TCP on 599 Smartphones", 17th International Passive and Active 600 Measurements Conference (PAM2016) , March 2016, 601 . 604 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 605 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 606 January 2006, . 608 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 609 (TLS) Protocol Version 1.2", RFC 5246, 610 DOI 10.17487/RFC5246, August 2008, 611 . 613 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 614 Iyengar, "Architectural Guidelines for Multipath TCP 615 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 616 . 618 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 619 Yasevich, "Sockets API Extensions for the Stream Control 620 Transmission Protocol (SCTP)", RFC 6458, 621 DOI 10.17487/RFC6458, December 2011, 622 . 624 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 625 Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, 626 March 2013, . 628 [SIGCOMM11] 629 Raiciu, C., Barre, S., Pluntke, C., Greenhalgh, A., 630 Wischik, D., and M. Handley, "Improving datacenter 631 performance and robustness with multipath TCP", 632 Proceedings of the ACM SIGCOMM 2011 conference , 2011, 633 . 635 Authors' Addresses 637 Benjamin Hesmans 638 UCLouvain 640 Email: Benjamin.Hesmans@uclouvain.be 642 Olivier Bonaventure 643 UCLouvain 645 Email: Olivier.Bonaventure@uclouvain.be