idnits 2.17.1 draft-samar-mptcp-socketapi-03.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 -- The document date (August 5, 2019) is 1725 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'HES2017' is defined on line 281, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP Working Group Samar Shailendra 3 Internet-Draft Hemant Kumar Rath 4 Intended status: Informational Arpan Pal 5 Expires: February 6, 2020 TCS R&I 6 Abhijit Mondal 7 IIT Kharagpur 8 August 5, 2019 10 Extended Socket APIs to control subflow priority in Multipath TCP 11 draft-samar-mptcp-socketapi-03.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on February 01, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Abstract 53 This document provides the extended Socket APIs to control subflow 54 priority for Multipath TCP. It also describes an additional data 55 structure for MPTCP to make the subflow priority persistent across 56 subflow disconnection. 58 Table of Contents 60 1. Introduction...................................................2 61 2. Socket APIs for subflow Priority...............................3 62 2.1. Control Subflow Priority..................................4 63 2.2. Remembering Subflow Priority..............................4 64 3. Security Considerations........................................5 65 4. IANA Considerations............................................5 66 5. Conclusions....................................................5 67 6. References.....................................................6 68 6.1. Normative References......................................6 69 6.2. Informative References....................................6 70 7. Authors' Addresses.............................................7 72 1. Introduction 74 Multipath TCP (MPTCP) [RFC6824, RFC6182] has been designed as a 75 successor to TCP [RFC0793] with complete backward compatibility i.e. 76 it is able to use the same TCP socket APIs as well as communicate 77 with the non-MPTCP enabled hosts. MPTCP is included in the mainline 78 Linux Kernel [MPLINUX]. It has also been used in various devices such 79 as iPhone [I-PHONE] to improve the reliability by concurrently 80 connecting the WiFi and the cellular interfaces. Currently, MPTCP has 81 implemented four path managers to effectively use multiple paths 82 between the source and the destination. 84 o Default: This path manager does nothing more than accepting the 85 passive creation of subflows. 87 o Full Mesh: This creates a full-mesh of subflows between all 88 available source and destination interfaces. Usually the subflows 89 are created by the client. 91 o Ndiffports: This path manager creates multiple subflows between 92 every source and destination pair. 94 o Binder: This is a relatively newer path manager included in the 95 list. It is based on Loose Source Routing [BOC2013]. 97 MPTCP is completely backward compatible with the TCP socket APIs. 98 However, these socket APIs do not exploit the complete potential of 99 MPTCP as these functionality are not available in TCP [RFC6824]. 100 Hence, it is not possible to provide fine grained control over MPTCP 101 and in some ways it restricts the usability of MPTCP. Since, defining 102 new system call is a big ask for MPTCP and application developers are 103 more used to controlling the behavior of TCP using socket option APIs 104 (setSockOpt and getSockopt), it is quite effective to develop new 105 socket APIs for MPTCP as well to control its behavior. 107 In their draft [HESID17], Hesmans et al. have proposed MPTCP socket 108 APIs to interact with the underlying socket and control the subflow 109 behavior e.g. getting the list of existing subflows, creation of new 110 subflow, termination of subflows etc.. In this draft, we use their 111 draft [HESID17] as the foundation and provide the extended socket 112 APIs to allow the application to mark a particular subflow as an 113 active or a backup subflow. Such a control is very helpful for the 114 applications which intend to send multiple data streams with 115 different Quality of Service (QoS) [SHA2017] requirements to another 116 application or end host. 118 By default MPTCP creates every new subflow as an active subflow. 119 Hence, if a backup or low priority subflow gets disconnected and 120 connects again, it becomes active i.e. it does not remember its 121 previous state. In this document we also provide a new data structure 122 to remember the states of subflows. Hence, if a particular subflow 123 between any source destination pair is restored after disconnection, 124 it restores with the same state. 126 The rest of the document is organized as follows: it gives the 127 details of the socket APIs and the corresponding getSockOpt and 128 setSockopt details. We than provide the details of data structure to 129 remember the subflow priority and the corresponding socket APIs and 130 the socket options. 132 2. Socket APIs for subflow Priority 134 In this section we present the new socket APIs for the subflow 135 priority control. Currently, MPTCP provides two possible priorities 136 for each subflow; high priority or active subflow, and low priority 137 or backup subflow. These socket APIs can enable the client or the 138 server to dynamically set the subflow priority. 140 For all socket APIs, the underlying connections are assumed to 141 Multipath TCP connections, otherwise these APIs return an error and 142 set the errono as "EOPNOTSUPP". 144 2.1. Control Subflow Priority 146 This document addresses a typical requirement for an application to 147 change the priority of a subflow without restarting the entire 148 connection. 150 The first important step to set the subflow priority is to get the 151 list of available subflows. This can be performed using the 152 "MPTCP_GET_SUB_IDS" socket option defined by Hensman et al.[ HESID17, 153 HES2017]. 155 The next step is to set the priority of a particular subflow. The 156 "MPTCP_SET_SUB_PRIO" socket option can be used to set the subflow 157 priority identified by its subflow id. This can be called by using 158 "setsockopt" with "MPTCP_SET_SUB_PRIO" as the socket option and 159 passing a pointer to "mptcp_sub_prio" structure. The "mptcp_sub_prio" 160 structure is defined as follows: 162 struct mptcp_sub_prio { 163 __u8 id; 164 __u16 low_prio; 165 }; 167 Here, "id" is the subflow id as returned by the get subflow socket 168 API and "low_prio" is priority value to be defined for the subflow. 169 Note that a subflow is an active subflow if the low_prio flag is set 170 to "0". A typical illustration of this API to set the sublfow 171 priority as backup is as follows: 173 struct mptcp_sub_prio fp = {5, 1}; //subflow id 5 is set to backup. 175 setsockopt(sockfd, IPPROTO_TCP, MPTCP_SET_SUB_PRIO,&fp, sizeof(fp)); 177 On successful return of the above socket API, MPTCP protocol sends 178 this information to remote host using MP_PRIO flag. 180 2.2. Remembering Subflow Priority 182 A new subflow in MPTCP is in active state and immediately starts 183 sending the data. If the subflow between a particular source and 184 destination is marked as backup using "MPTCP_SET_SUB_PRIO", it 185 becomes active if the subflow gets disconnected and connects again or 186 a new subflow is created. To handle this situation, two new lists 187 "ActiveInterfaceList" and "BackupInterfaceList" are included in MPTCP 188 to remember the state of the subflows between two end hosts. To 189 resolve any inconsistency between the two lists, the former has been 190 assigned a higher priority than the later. 192 To populate the active and backup lists, setsockopt with 193 "MPTCP_SUB_PATH_ACTIVE_LIST" and "MPTCP_SUB_PATH_BACKUP_LIST" 194 respectively can be used. This requires the application to pass the 195 pointer to "MPTCP_SUB_PATH" structure. The "MPTCP_SUB_PATH" is 196 defined as follows: 198 struct mptcp_sub_path { 199 sa_family_t sa_family; 200 union { 201 struct in_addr sin_addr; 202 struct in6_addr sin6_addr; 203 }; 204 union { 205 struct in_addr din_addr; 206 struct in6_addr din6_addr; 207 }; 208 }; 210 These lists can be updated any time; however the runtime update will 211 not change the state of an existing subflow. Hence, this socket APIs 212 must be called before the subflows are created. 214 3. Security Considerations 216 There are no new security considerations for this document. 218 4. IANA Considerations 220 There are no IANA considerations in this document. 222 5. Conclusions 224 This document provides extended socket APIs for MPTCP to control the 225 subflow priorities. These are expected to be very useful for those 226 applications which want a fine grained control over the data to be 227 sent over the available subflows between the end hosts. These APIs 228 can increase the versatility of MPTCP subflows and also provide an 229 opportunity to the application developers to select the subflows more 230 intelligently. This is expected to be useful for different scenarios 231 and devices e.g. drones [SHA2017, RAO2017] where it is important to 232 segregate control data from user data on different subflow. 234 6. References 236 6.1. Normative References 238 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC793, 239 DOI 10.17487/RFC0793, September 1981, 240 . 242 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,"TCP 243 Extensions for Multipath Operation with Multiple 244 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 245 . 247 [HESID17] B. Hesmans and O. Bonaventure, "A socket API to control 248 Multipath TCP", Internet Draft, July 2017, 249 https://tools.ietf.org/html/draft-hesmans-mptcp-socket-02. 251 [MPLINUX] "Multipath TCP implementation in the Linux kernel", 252 . 254 6.2. Informative References 256 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 257 Iyengar, "Architectural Guidelines for Multipath TCP 258 Development", RFC6182, DOI 10.17487/RFC6182, March 2011, 259 . 261 [I-PHONE] Apple Inc, "iOS - Multipath TCP Support in iOS7", 262 . 264 [BOC2013] L. Boccassi, M. M. Fayed, and M. K. Marina, "Binder: A 265 System to Aggregate Multiple Internet Gateways in Community 266 Networks," in Proceedings of the 2013 ACM MobiCom Workshop 267 on Lowest Cost Denominator Networking for Universal Access. 268 ACM, 2013, pp. 3-8. 270 [SHA2017] S. Shailendra, K. Aniruddh, B. Panigrahi, and A. Simha, 271 "Multipath TCP Path Scheduler for Drones - A Segregation of 272 Control and User Data," in Proceedings of the 18th ACM 273 International Symposium on Mobile Ad Hoc Networking and 274 Computing. ACM, 2017. 276 [RAO2017] A. Rao, M. Visali, S. Shailendra, B. Panigrahi, and A. 277 Simha, "Reliable Robotic Communication using MPTCP," in 9th 278 International Conference on Communication Systems and 279 Networks, Jan 2017, pp. 429-430. 281 [HES2017] B. Hesmans and O. Bonaventure, "An enhanced socket API for 282 Multipath TCP," in Proceedings of the 2016 Applied 283 Networking Research Workshop. ACM, 2016, pp. 1-6. 285 7. Authors' Addresses 287 Samar Shailendra 288 TCS Research & Innovation 289 Bangalore, India 291 Email: s.samar@tcs.com 293 Hemant Kumar Rath 294 TCS Research & Innovation 295 Bhubaneswar, India 297 Email: Hemant.rath@tcs.com 299 Arpan Pal 300 TCS Research & Innovation 301 Kolkata, India 303 Email: arpan.pal@tcs.com 305 Abhijit Mondal 306 Indian Institute of Technology Kharagpur 307 Kharagpur, India 309 Email: abhimondal@iitkgp.ac.in