idnits 2.17.1 draft-kang-tcpm-accurate-data-scheduling-by-server-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 July 2020) is 1384 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0793' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'RFC6824' is defined on line 268, but no explicit reference was found in the text == Unused Reference: 'RFC8684' is defined on line 273, 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: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions J. Kang, Ed. 3 Internet-Draft Q. Liang 4 Intended status: Informational Huawei 5 Expires: 14 January 2021 13 July 2020 7 Accurate Data Scheduling by Server in MPTCP 8 draft-kang-tcpm-accurate-data-scheduling-by-server-00 10 Abstract 12 This document defines a new mechanism that enables server to send 13 request to client for data scheduling between the subflows during a 14 MPTCP session. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 14 January 2021. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Typical flows for accurate data scheduling by server . . . . 3 51 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. Traffic switching to a newly-added network interface . . 5 53 3.2. Traffic switching to a network interface already in the 54 session . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. MP_Navigation Option . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 MPTCP protocol is now being deployed in more and more networks. In 66 most scenarios, MPTCP scheduling strategies for these subflows are 67 implemented on client side considering RTT and congestion, or sending 68 packets redundantly. Application server cannot actively participate 69 in such decision-making. 71 However in real deployment, application server supports multiple 72 network interfaces from different operators when MPTCP protocol is 73 adopted. There are such scenarios that the server wants to set 74 scheduling to the client on these network interfaces based on server- 75 side rules in a MPTCP session. The requirements for these use cases 76 are listed below: 78 * Network fault prevention. Server tools can detect network quality 79 of deployed network interfaces such as packet Loss, delay and 80 jitter. When the key performance indicators (KPI) become worse, 81 the server hope to switch the traffic to a network interface with 82 better KPI. 84 * Broadband entrances from different operators or the emergency 85 entrance of 5G card are added. This change is dynamic throughout 86 the session and the operator hope to reduce the load on some 87 subflows and lead them to the additional subflow, such as for 88 test. This is the trial operation scenario for new network. 90 * Value-added services. Operator wants to provide customers with 91 diversified services to satisfy individual demand. For example, 92 for VIP users, it should be possible to switch their traffic to 93 network interface with better network KPIs. 95 * Another typical scenario is that operator hope to adjust traffic 96 to a specific subflow for the changes in network cost, for 97 example, the expiration of discounts. 99 There are two related implementations. RFC8684 defines REMOVE_ADDR 100 Option to delete one address during a MPTCP session and it also 101 closes all subflows bound to this address. draft-hoang-mptcp-sub- 102 rate-limit-00 proposes a Subflow Rate Limit Option which can be used 103 by sender to receiver for setting the rate of one subflow to zero. 104 But for the use cases in this document, existing technologies are 105 somewhat inadequate because they do not provide a clear indication of 106 which subflow to switch to. 108 2. Typical flows for accurate data scheduling by server 110 This document proposes an accurate data scheduling mechanism for 111 server. Two typical flows are illustrated in Figure 1 and Figure 2. 113 +--------+ +--------+ 114 | Client | | Server | 115 +--------+ +--------+ 116 | | 117 |<----Session setup with subflows----->| 118 | | 119 | Determine Address ID 120 | for target network Interface 121 | | 122 |<--Sending MP_Navigation for request--| 123 | on one ongoing subflow | 124 | | 125 Determine target subflow | 126 by Address ID in MP_Navigation | 127 | | 128 Traffic switching to | 129 the target subflow | 130 | | 131 |----Data transfer over the target---->| 132 | subflow of target network interface | 133 | | 134 | | 136 Figure 1: Server request client to perform traffic switching 137 +--------+ +--------+ 138 | Client | | Server | 139 +--------+ +--------+ 140 | | 141 |<---Subflow with diverted traffic --->| 142 | is still kept alive | 143 | | 144 | Determine to cancel MP_Navigation 145 | for target network Interface 146 | | 147 |<----Sending MP_Navigation on the-----| 148 | subflow with diverted traffic | 149 | for cancellation | 150 | | 151 Cancel traffic switching to | 152 target network interface | 153 on the MP_Navigation | 154 | | 155 |-----Continue data transfer over----->| 156 | the subflow with diverted traffic | 157 | | 158 | | 160 Figure 2: Server sends a request to client to cancel previous 161 navigation setting 163 For the use case of adding a new network interface to MPTCP session 164 for navigation, normal process of ADD_ADDR should be executed before 165 traffic switching. 167 If it is determined to cancel the data switching on the subflow, the 168 client should delete the navigation information. The navigation 169 information is generated by the client and is used to determine the 170 target subflow for data switching based on the address ID of the 171 target network interface. 173 After data switching, if the subflow with diverted traffic is 174 disconnected, the client should delete the navigation information and 175 configuration information for it. The navigation information is 176 generated by the client and is used to determine the target subflow 177 for data switching based on the address ID of the target network 178 interface. 180 3. Examples 181 3.1. Traffic switching to a newly-added network interface 183 Four subflows have been established between client and server that 184 are , , and . On the 185 client, IP1 and IP2 are the address IDs for WiFi and a cellular 186 network. On the server, IP3 and IP4 are the address IDs for Ethernet 187 and WiFi. When a new 5G network is deployed on the server, the 188 server can switch the data traffic on the subflow to the 189 destination IP5 corresponding to 5G. In this case, the target 190 network interface is IP5. 192 3.2. Traffic switching to a network interface already in the session 194 Four subflows have been established between client and server that 195 are , , and . On the 196 client, IP1 and IP2 are the address IDs for WiFi and a cellular 197 network. On the server, IP3 and IP4 are the address IDs for Ethernet 198 and WiFi. Server tool detects that KPI for IP4 is better now so the 199 server can switch data traffic on the subflow to the 200 destination IP4. 202 4. MP_Navigation Option 204 In this solution, a MP_Navigation option is defined and sent from 205 server to forces client to switch traffic from the subflow over which 206 the option was received to a target subflow or to cancel the traffic 207 switching when it is not required, which is indicated by a flag 'R'. 208 If it is set, the target subflow is determined through the Address ID 209 of the target network interface in MP_Navigation option. 211 This MP_Navigation Option can be sent in ACK. 213 It is noted that if this option is not supported by the client, it 214 should be omitted. 216 4.1. Option Format 218 The format of the MP_Navigation option is depicted in Figure 3: 220 1 2 3 221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 222 +---------------+---------------+-------+-------+---------------+ 223 | Kind | Length |Subtype|r|R|E|B| Address ID | 224 +---------------+---------------+-------+-------+---------------+ 226 Figure 3: MP_Navigation Option 228 Subtype: A new subtype should be allocated to indicate MP_Navigation 229 Option. 231 Address ID: Address ID in MP_Navigation Option is used to identify 232 the address ID of target network Interface. 234 The flag 'R', when set, define the content of this option, as 235 follows: 237 * When value of 'R' is set to zero, server want to use this option 238 to inform client of navigation policy and the client will perform 239 traffic switching as requested by the server. When value of 'R' 240 is set to 1, the server requests to cancel current navigation 241 policy in client and the client will delete corresponding 242 navigation information to the Address ID. 244 When the client receives the MP_Navigation Option, it will determine 245 the target network interface by the Address ID. Address ID may map 246 to one or more ongoing subflows and the client will select one for 247 each data transfer by its local strategies. 249 5. IANA Considerations 251 IANA is requested to assign a MPTCP option subtype for the 252 MP_Navigation option. 254 6. Security Considerations 256 Since MP_Navigation Option is neither encrypted nor authenticated, 257 on-path attackers and middleboxes could remove, add or modify the 258 MP_Navigation Option on observed Multipath TCP connections. 260 7. References 262 7.1. Normative References 264 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 265 RFC 793, DOI 10.17487/RFC0793, September 1981, 266 . 268 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 269 "TCP Extensions for Multipath Operation with Multiple 270 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 271 . 273 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 274 Paasch, "TCP Extensions for Multipath Operation with 275 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 276 2020, . 278 Authors' Addresses 280 Jiao Kang (editor) 281 Huawei 282 D2-03,Huawei Industrial Base 283 Shenzhen 284 China 286 Phone: +86 18520828326 287 Email: kangjiao@huawei.com 289 Qiandeng Liang 290 Huawei 291 No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone 292 Wuhan 293 China 295 Phone: +86 18651640216 296 Email: liangqiandeng@huawei.com