idnits 2.17.1 draft-nagesh-mptcp-feature-negotiation-ps-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 4, 2019) is 1633 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3168' is defined on line 340, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP N. Shamnur 3 Internet-Draft Z. Cao 4 Intended status: Informational Huawei 5 Expires: May 7, 2020 November 4, 2019 7 Problem Statement of MPTCP Transmission Feature Negotiation 8 draft-nagesh-mptcp-feature-negotiation-ps-01 10 Abstract 12 Path manager and packet scheduler are two important components of 13 MPTCP protocol and associated implementations. Normally they are 14 implemented and configured statically. This draft discusses the 15 scenarios where statically configured path manager and packet 16 scheduler are not sufficient, and presents the cases that deserve the 17 negotiation of these multipath transmission features which are 18 currently not addressed by MPTCP. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 7, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language and Terminology . . . . . . . . . . 3 56 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Current multipath transmission strategies . . . . . . . . 3 58 2.2. Current practice to overcome this limitation . . . . . . 4 59 2.3. Problems with current method of tranmission strategies 60 configuration . . . . . . . . . . . . . . . . . . . . . . 4 61 2.4. Deployment scenario . . . . . . . . . . . . . . . . . . . 5 62 2.4.1. Scheduler deployment scenario . . . . . . . . . . . . 5 63 2.4.2. Path Manager deployment scenario . . . . . . . . . . 6 64 3. Requirements for multipath transmission negotiation 65 strategies . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Req#1: Flexiblity at each endpoint to implement 67 propreitary algorithms . . . . . . . . . . . . . . . . . 7 68 3.2. Req#2: Flexiblity to be configured based on deployment 69 network . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.3. Req#3: Flexiblity to be configured based on application 71 used . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 MPTCP [RFC6824] [I-D.ietf-mptcp-rfc6824bis] specifies the procedure 80 of establishing multiple subflows to a connection and it also 81 explains the procedures for path management. There are various types 82 of path manager that can be configured. The selection of a 83 particular path manager algorithm is however decided based on the 84 deployment scenario and hence multiple options for the same are 85 available. Each end of the MPTCP connection needs to configure a 86 path manager algorithm that would be used for a particular connection 87 in isolation and would thus wouldn't know the path manager chosen on 88 the remote side. In certain cases, a combination of different types 89 of configuration would be required to suit a particular deployment 90 scenario. 92 This limitiation is also true in the case of the scheduler as well. 93 Since for every connection server based on its local policies selects 94 a particular scheduler and the client would select its own based on 95 it's own local policies for data transmission to a remote endpoint. 96 A particular scheduler type thus selected at the server would suit a 97 connection to a particular client but the same might not be optimal 98 in case of another client. This intelligence will have to be 99 provisioned at the server using offline methods and server would not 100 be updated in time about any changes that happen on the client-side 101 and so limits server from switching to the optimal scheduler to 102 attain the best possible network bandwidth usage. 104 MPTCP [RFC6824] does not standardises the rules for selection of 105 either of path manager or scheduler that needs to be configured at 106 each endpoint of the MPTCP connection and leaves it to implementors` 107 choice. Many factors influence the choice of path manager and 108 scheduler method that needs to be applied on each side. Linux Kernel 109 implements 4 different path managers - default, full-mesh, ndiffports 110 and binder. It also implements 3 different schedulers - default 111 (minRTT), round-robin and redundant. In reality, though not adopted 112 by the current open source MPTCP, tens of schedulers are implemented, 113 experimented and adapted by various people and institutions based on 114 the deployment scenarios. 116 This document explains the set of problem associated with the current 117 MTPCP [RFC6824] with respect to rules for choosing and selecting the 118 path manager and scheduler that needs to be configured and the 119 problem it creates due to the absence of synchronisation mechanism 120 which hinders the subflows from achieving the best results for path 121 aggregation, optimal bandwidth utilization and reap the benefits of 122 switching to MPTCP from TCP. This document also discusses and 123 emphasizes the needs for a procedure to exchange the capabilities 124 during the connection establishment as well as during the lifetime of 125 the connection. 127 1.1. Requirements Language and Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 This document also uses terminology described in [RFC6824]. 135 2. Rationale 137 2.1. Current multipath transmission strategies 139 Before establishing an MPTCP connection between the desiring peers, 140 at each end of the connection endpoint, a choice of scheduler and 141 path manager needs to be made based on the deployment strategy and 142 the quality of the heterogeneous link(s) on which connection gets 143 established. Once selected, the same needs to be statically 144 provisioned and the connection establishment procedure follows. 146 Both Scheduler and Path Manager are features which are not 147 standardized by IETF and is implementation-dependent. Various 148 factors including deployment scenario influence the choice of 149 scheduler/path manager that would be applied for every connection. 150 One size fits all approach hence cannot be applied. Either of Client 151 or Server can choose any of the publicly available standards 152 implementation or can have its own implementation of a scheduler and 153 path manager. At the same time, it can also expect the far endpoint 154 of the connection to configure the scheduler and path manager to be 155 configured in a certain way so as to achieve the desired result for 156 both upstream and downstream data. MPTCP [RFC6824] doesn't explains 157 how the schedulers/path managers are configured on each side of the 158 connection and how it would be synchronized at the time of connection 159 setup. 161 Absence of such a mechanism forces endpoints to negotiate them 162 offline and also it would not be easy to change it in the deployed 163 systems. This in turn inhibits MPTCP to deploy application and 164 preference aware schedulers and path managers. Moreover, it would 165 not permit to change the schedulers and path managers that are 166 configured at each endpoint and synchronize them between client and 167 servers, if the network conditions change. 169 2.2. Current practice to overcome this limitation 171 Schedulers and Path Managers are statically provisioned at each end 172 of the endpoint and in a specific way. Client and server configure 173 Schedulers/path managers in isolation and may or may not be 174 synchronized with each other. For synchronization out of band, 175 method can be used which would not be discussed as a part of this 176 document. Path aggregation results might vary in each direction of 177 the connection due to this difference in configuration between server 178 and client. 180 ECN [RFC3168]can help acheive the goal of scheduler to a fair extent 181 by setting the CE mark. However, this solution has some limitations 182 per a brief discussion at IETF104 [minutes]. (it throttles the cwnd 183 size when the flow really needs it) 185 2.3. Problems with current method of tranmission strategies 186 configuration 188 Both server and client needs to negotiate the capabilities that will 189 be configured on each side offline and cannot be discovered 190 dynamically when the connection is initiated by the client. A wrong 191 configuration decision can have a substantial impact on protocol 192 performance. A wrong decision may render the advantage of additional 193 paths useless or even reduce the overall performance by introducing 194 issues like head-of-line blocking. Clients having proprietary 195 implementation cannot expect to have the desired result for both 196 upstream and downstream data without setting the configuration on the 197 far end of the connection. Also, it might not be viable to patch or 198 provision a new scheduler and/or path manager on server-side for 199 every new client that connects to it might have already been 200 deployed. A server cannot configure differentiated schedulers/path 201 managers based on a different client that connects to it. 203 2.4. Deployment scenario 205 2.4.1. Scheduler deployment scenario 207 In one typical deployment scenario, the mptcp is used between a 208 smartphone and a cloud server. There are two subflows in the 209 connnection, one over the 802.11 path, and the other one via the 210 cellular path. The application running on top of mptcp would like to 211 optimize its performance in terms of latency and throughput. 212 However, the smartphone user would like to use the toll-free 802.11 213 link as much as possible, and only overflow to cellular link when 214 necessary. For the upstream traffic, the smartphone can control the 215 user expectation based on its own scheduler. However the server does 216 not know which path is preferred and which one is not, since the path 217 characteristics have not been informed to the server. In this sense, 218 the mptcp scheduler on the server is not able to schedule the packet 219 according to the service requirement. 221 (((......))) 222 ((( ))) 223 ((( ))) 224 ((( ))) 225 ((( Cloud ))) 226 ((( Platform ))) 227 ((( ))) 228 ((( ))) 229 ((( ))) 230 (((......))) 231 ^ |v | 232 > > > > > > > > |v | 233 ^ |v | 234 ^ +--------------+v +--------------+ 235 ^ | v | 236 ^ | < < < < < < < | 237 ^ | v | 238 ^ | v | 239 ^ | v | 240 +---------+ +---------+ 241 | 802.11 | | LTE | 242 +---------+ +---------+ 244 Figure 1: Scheduler Deployment scenario 246 2.4.2. Path Manager deployment scenario 248 A bit different to the previous scenario, the smartphone is connected 249 to the server over a mptcp connection via a 802.11 path and a 250 cellular link. However the server also has two IP addresses from two 251 ISPs. Ideally, the client path manager needs to avoid the creation 252 of sub-flow on the cross path since cross paths are deemed to be less 253 efficient in terms of bandwidth availability and latency. This 254 scheme needs to be realized by setting the path manager on the 255 client-side to proprietary and default mode on the server-side, so 256 that only the client initiates the sub-flow creation and avoids 257 creating cross-path sub-flows to server. This, however, can only be 258 cooridinated manually in the current mptcp design. 260 Most recently, the mptcp upstream project has put the user space path 261 manager into the roadmap [mptcpd], which is quite align with the 262 scenario we have described. This will bring the path-manager 263 negotiation goal closer to reality. 265 +-----------+ +-----------+ 266 | |+------+ +------+| | 267 | ||802.11| - - - - - - - - |802.11|| | 268 | |+------+ \ / +------+| | 269 | | \ / | | 270 | Client | x | Server | 271 | | / \ | | 272 | |+------+ / \ +------+| | 273 | || LTE | - - - - - - - - | LTE || | 274 | |+------+ +------+| | 275 +-----------+ +-----------+ 277 Figure 2: Path Manager Deployment scenario 279 3. Requirements for multipath transmission negotiation strategies 281 3.1. Req#1: Flexiblity at each endpoint to implement propreitary 282 algorithms 284 Each endpoint of the connection should be equipped to implement 285 proprietary implementation of scheduler and path manager. The same 286 also should be allowed to be commissioned dynamically and can be 287 synchronized with the peer endpoint on a per-connection basis. This 288 would increase the flexibility to deploy MPTCP under various 289 heterogeneous network conditions without the need to recompile the 290 kernel/implementation. 292 3.2. Req#2: Flexiblity to be configured based on deployment network 294 As mentioned in the earlier section Section 2.1 there is no universal 295 method which satisfies all the various heterogeneous networks in 296 which MPTCP gets deployed and so different network scenario demands 297 different implementation for scheduler and path manager. At the 298 server, a system need to support commissioning of different methods 299 for schedulers and path managers based on the client which connects 300 to it. 302 3.3. Req#3: Flexiblity to be configured based on application used 304 Multipath TCP scheduling and path manager is configured in isolation 305 and application bear no impact on the choice of scheduler and path 306 manager that gets configured in the MPTCP layer. Different 307 applications will demand different selection of these capabilities 308 and thus the monolithic configuration of the same severely restricts 309 the advantages of deploying MPTCP. Application-aware selection of 310 these methods would thus push MPTCP beyond throughput optimization 311 and thus can be deployed in a wide range of applications. 313 4. IANA Considerations 315 This specification contains no IANA considerations. 317 5. Security Considerations 319 TBD. 321 6. Normative References 323 [I-D.ietf-mptcp-rfc6824bis] 324 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 325 Paasch, "TCP Extensions for Multipath Operation with 326 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-18 (work 327 in progress), June 2019. 329 [minutes] 104, I., "https://tools.ietf.org/wg/mptcp/ 330 minutes?item=minutes-104-mptcp-00.html", August 2019. 332 [mptcpd] mptcpd, "The Multipath TCP Daemon, 333 https://github.com/intel/mptcpd/", August 2019. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 341 of Explicit Congestion Notification (ECN) to IP", 342 RFC 3168, DOI 10.17487/RFC3168, September 2001, 343 . 345 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 346 "TCP Extensions for Multipath Operation with Multiple 347 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 348 . 350 Authors' Addresses 352 Nagesh Shamnur 353 Huawei 354 Kundalahalli Village, Whitefield, 355 Bangalore, Karnataka 560037 356 India 358 Phone: +91-080-49160700 359 Email: nagesh.shamnur@gmail.com 360 Zhen Cao 361 Huawei 362 Xinxi No.3 363 Beijing 100085 364 China 366 Email: zhencao.ietf@gmail.com