idnits 2.17.1 draft-wing-mptcp-pcp-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 : ---------------------------------------------------------------------------- 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 (October 07, 2013) is 3826 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-pcp-proxy' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC5245' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'RFC6724' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC6296' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC6356' is defined on line 396, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-04 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Downref: Normative reference to an Informational RFC: RFC 6182 ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) ** Downref: Normative reference to an Informational RFC: RFC 6897 == Outdated reference: A later version (-04) exists of draft-deng-mif-api-session-continuity-guide-03 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP D. Wing 3 Internet-Draft R. Ravindranath 4 Intended status: Standards Track T. Reddy 5 Expires: April 10, 2014 Cisco 6 A. Ford 7 Unaffiliated 8 R. Penno 9 Cisco 10 October 07, 2013 12 Multipath TCP (MPTCP) Path Selection using PCP 13 draft-wing-mptcp-pcp-00 15 Abstract 17 MultiPath TCP (MPTCP) allows a host to use multiple interfaces to 18 transfer data. Without knowledge of the characterisitcs of each 19 network path, the MPTCP stack has to send data to learn those 20 characteristics. This document communicates network characteristics 21 using Port Control Protocol(PCP) to allow the MPTCP stack influence 22 its functions. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 10, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 60 3. MPTCP stack using PCP . . . . . . . . . . . . . . . . . . . . 4 61 4. Multiple Interfaces . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Interface Availability . . . . . . . . . . . . . . . . . 6 63 4.1.1. consolidate subflows . . . . . . . . . . . . . . . . 7 64 4.1.2. migrating an existing subflow . . . . . . . . . . . . 7 65 5. Switch-over . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Using MP_PRIO mechanism of MPTCP along with PCP . . . . . . . 7 67 7. PCP Instance ID usage in MPTCP flows . . . . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 10.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Multipath Transmission Control Protocol (MPTCP) [RFC6182] pools 78 multiple TCP paths within a transport connection, and is transparent 79 to the application. Multipath TCP is primarily concerned with 80 utilizing multiple paths end-to-end, where one or both of the end 81 hosts are multihomed. It may also have applications where multiple 82 paths exist within the network and can be manipulated by an end host. 83 An MPTCP connection begins similarly to a regular TCP connection and 84 if extra paths are available, additional TCP subflows are created on 85 these paths, and are combined with the existing session, which 86 continues to appear as a single connection to the applications at 87 both ends. MPTCP provides greater throughput by using multiple 88 paths, and also resilience against path failure. The latter property 89 additionally provides mobility functionality. 91 MPTCP identifies multiple paths by the presence of multiple addresses 92 at hosts. The discovery and setup of additional subflows will be 93 achieved through a path management method. Section 3.3.8 of 94 [RFC6824] discusses MPTCP policies to share traffic over the 95 available paths. MPTCP may use all paths (for maximum throughput) or 96 a subset of paths (for network resiliency). The path selection is 97 mostly based on local policy, OS behavior, and the MP_PRIO option. 99 The MPTCP API document [RFC6897] discusses the requirements for 100 MPTCP-aware applications to select multiple paths that can provide 101 the required flow characteristics; for example, 5Mbps of upstream/ 102 downstream bandwidth, low loss, low delay, etc. Appendix A.3 of 103 [RFC6897] lists two requirements (REQ-8, REQ-9) for an advanced MPTCP 104 API which would enable the application to select paths based on the 105 link characteristics like bandwidth, latency, etc. 107 This draft defines the on-the-wire protocol for such an advanced 108 MPTCP API. It uses PCP flow extensions [I-D.wing-pcp-flowdata] to 109 select the best path when multiple paths are available. This would 110 be particularly relevant for applications that are highly interactive 111 but require specific link characteristics such as certain minimum 112 upstream or downstream bandwidth, delay, loss, or jitter 113 characteristics. In such a situation, the MPTCP stack can use PCP to 114 find a interface that provides the necessary characteristics. The 115 network could even acquire the required charactertics (e.g., by 116 assigning bandwidth to the user). The MPTCP stack may start one or 117 more additional subflows that are not immediately used, but are 118 available as "hot standby" for resilience and recovery purposes. PCP 119 can be used to find those additional paths that meet the flow 120 characteristics to handle future failover. 122 Readers are assumed to be familiar with MPTCP and PCP [RFC6887]. 124 2. Notational Conventions 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 This document uses the terminology defined in MPTCP Architecture 131 [RFC6182], Multipath TCP [RFC6824] andPort Control Protocol 132 [RFC6887]. 134 3. MPTCP stack using PCP 136 This section describes the algorithm a MPTCP stack can use with PCP 137 extensions. The application would signal the flow characteristics to 138 the MPTCP stack. For example, the MPTCP stack would receive an 139 abstract request from the application to provide a low-latency, low- 140 jitter, n-Mbps of upstream bandwidth and m-Mbps of downstream 141 bandwidth service. The MPTCP stack would send PCP flow extension 142 requests to the default router on each interface, receive PCP flow 143 extension responses indicating the network characteristics, and tune 144 the MPTCP stack accordingly to favor certain interfaces over other 145 interfaces. 147 Host 148 +-----------------------------------------+ 149 | | 150 | | 151 | +-------------------------------+ | 152 | | Application | | 153 | +-------------------------------+ | 154 | ^ | 155 | | | 156 | v | 157 | +---------------+---------------+ | 158 | | MPTCP | PCP Client | | 159 | | stack <------> | | 160 | + - - - - - - - + - - - - - - - + | 161 | | Subflow (TCP) | UDP | | 162 | +-------------------------------+ | 163 | | IP | IP | | 164 | +-------------------------------+ | 165 +-----------------------------------------+ 167 Figure 1: MPTCP stack using PCP 169 The below steps briefly describe how a MPTCP stack uses the PCP 170 FLOWDATA option: 172 1. The application requests the MPTCP stack to setup a connection 173 towards a server/remote peer. The MPTCP stack discovers all the 174 available interfaces and gathers the source addresses from these 175 interfaces. This includes addresses from different interfaces 176 (in the case of the host having multiple interfaces), or from the 177 same interface (Multihoming), and also confirms that PCP Flow 178 Extensions is supported. 180 2. The application signals the required flow characteristics to the 181 MPTCP stack via a API (such as the abstract API described in 182 Appendix A of [RFC6897]). After getting the flow 183 characteristics, the MPTCP stack uses the PCP client to send PCP 184 MAP opcode with FILTER (section 11 of [RFC6887]) and FLOWDATA 185 options (section 3 of [I-D.wing-pcp-flowdata]) to signal the flow 186 characteristics like bandwidth, loss, delay, etc to multiple PCP 187 servers. 189 3. After receiving the PCP Flow extension responses from multiple 190 PCP servers, the MPTCP stack sorts the source addresses according 191 to the link characteristics. 193 4. The MPTCP stack picks the source address from the above sorted 194 list and uses the procedures explained in [RFC6824] to send a SYN 195 with MP_CAPABLE flag set to indicate to the server (peer) that 196 this host is MPTCP capable, in order to initiate the primary 197 subflow. 199 5. If the server supports MPTCP then the stack will either choose to 200 create subsequent subflows using the sorted source address list 201 from step 3 for resiliency purposes, or for use in parallel with 202 the primary subflow to exchange data at a higher throughput. The 203 choice here will likely depend on the stack's interpretation of 204 the application's required flow characteristics. 206 6. Any changes to the path characteristics that the PCP client 207 receives will be indicated to the MPTCP stack which then may 208 chose to migrate a subflow or consolidate subflows. 210 7. MPTCP stack can use PCP to communicate with PCP-controlled NAT to 211 learn external IP address, port and adverstise in ADD_ADDR MPTCP 212 option to the remote peer. MPTCP stack can also use PCP to 213 communicate with PCP-controlled firewall to permit incoming TCP 214 connections from the remote peer. 216 +--------+ 217 +-----------+ | +---------- { ISP-A } 218 | App |---+ router | 219 +-----------+ | +---------- { ISP-B } 220 +--------+ 222 App with MPTCP stack PCP server PCP Server 223 and PCP client (ISP A) (ISP B) TCP server 224 ------------------------ | | | 225 Address A Address B | | | 226 --------- ---------- | | | 227 | | | | | 228 | | | | | 229 |-PCP MAP + FLOWDATA-------->| | | 230 | | | | | 231 | |--PCP MAP + FLOWDATA------->| | 232 | | | | | 233 |<-SUCCESS-------------------| | | 234 | | | | | 235 | |<-SUCCESS-------------------| | 236 | | | | | 237 | ISP A is the best path indicated by PCP| | 238 | | | | | 239 |------------TCP SYN(MP_CAPABLE)--------------------------->| 240 |<-----------TCP SYN+ACK (MP_CAPABLE)---------------------->| 241 |------------TCP ACK (MP_CAPABLE)-------------------------->| 242 | | | | | 243 | | | | | 244 | Setup additional subflows | | 245 | | | | | 246 | |------------TCP SYN(MP_JOIN)--------------->| 247 | |<-----------TCP SYN+ACK (MP_JOIN)-----------| 248 | |------------TCP ACK (MP_JOIN)-------------->| 249 | | | | | 251 Figure 2: MPTCP stack using PCP 253 4. Multiple Interfaces 255 An MPTCP session begins similarly to a regular TCP connection. If 256 multiple paths are available, the MPTCP stack can use PCP flow 257 extensions [I-D.wing-pcp-flowdata] to determine the best path. The 258 advantage is PCP can be used to select the most suitable paths 259 instead of having MPTCP stack try out all paths. When a host has 260 multiple interfaces available (for example 3G/4G, WiFi, VPN etc), an 261 MPTCP application or the MPTCP stack can choose the interface for the 262 primary subflow and interfaces for subsequent subflows according to 263 the path characteristics, as discussed in the previous two sections. 265 4.1. Interface Availability 267 A MPTCP stack using the procedures described in 268 [I-D.deng-mif-api-session-continuity-guide] will be notified whenever 269 existing interfaces become unavailable or new interfaces are 270 available. For example the MPTCP stack implementation in the Linux 271 kernel is aware of the changes in the availability of interfaces and 272 can react accordingly. 274 In such cases the MPTCP stack can use PCP to consolidate sublows or 275 migrate an existing subflow, as described below. 277 4.1.1. consolidate subflows 279 When a new interface is discovered, the MPTCP stack can use PCP flow 280 extensions to determine the link characteristics of the new path. If 281 the new path can provide the required flow characteristics then MPTCP 282 could reduce the number of subflows in use. For example, assume 283 three subflows were in use to meet the application bandwidth demand: 284 the primary path providing bandwidth of 2Mbps, the secondary path 285 providing 1Mbps, and the tertiary paths 2Mbps. If PCP determines 286 that the new path can provide 3Mbps, then one subflow can be set up 287 in the new path and, and some of the subflows can be migrated to this 288 new path and thus reduce the number of subflows by closing the old 289 ones. Other factors like jitter, delay, and loss MAY also be 290 considered in the decision to migrate subflows. 292 4.1.2. migrating an existing subflow 294 When a existing interface becomes unavailable, the MPTCP stack picks 295 the unused interfaces and uses PCP flow extensions to determine the 296 interfaces which can provide the required flow characteristics. 297 MPTCP stack will follow the previously described steps to pick one or 298 more of the unused interfaces for creating additional subflows. 300 5. Switch-over 302 It is possible that the characteristics of a link might change over 303 time, and the MPTCP stack might want to move the subflow to a 304 different interface. For example, if a competing high-bandwidth flow 305 has finished, more bandwidth is available for the MPTCP flow; the DSL 306 line rate might have improved (or degraded); the link speed may have 307 been dynamically increased (or decreased). When link quality changes 308 in such a fashion, a PCP server will send PCP response which could 309 carry a FLOWDATA option where the data fields contain different 310 values from the first response. Upon receiving PCP response, the 311 MPTCP stack can tune its behavior (e.g., increase or decrease traffic 312 on the interface that is now more or less favorable). 314 6. Using MP_PRIO mechanism of MPTCP along with PCP 316 MPTCP has a priority mechanism, MP_PRIO, for setting a path to be 317 backup flow. This allows additional subflows to be set up but not 318 used until no higher priority subflows are available, allowing fast 319 fail-over. The MP_PRIO value of a subflow can be changed during the 320 lifetime of the session. A PCP server could send a notification to 321 the PCP client whenever path characteristics change, thus the PCP 322 client can indicate the same to the MPTCP stack which could change 323 the MP_PRIO values for the associated subflow(s) and trigger switch- 324 over appropriately. 326 7. PCP Instance ID usage in MPTCP flows 328 The instance identifier field in PCP flow extensions would help the 329 PCP server to co-relate multiple subflows that are part of the same 330 MPTCP session. The instance ID can be also be used by the service 331 provider to co-relate all the subflows of a MPTCP session. 333 8. IANA Considerations 335 None. 337 9. Security Considerations 339 Security considerations discussed in [RFC6887] are to be taken into 340 account. 342 Security considerations discussed in [RFC6824] are to be taken in to 343 account when creating new TCP subflows. 345 10. References 347 10.1. Normative References 349 [I-D.ietf-pcp-proxy] 350 Boucadair, M., Penno, R., and D. Wing, "Port Control 351 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-04 352 (work in progress), July 2013. 354 [I-D.wing-pcp-flowdata] 355 Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", 356 draft-wing-pcp-flowdata-00 (work in progress), July 2013. 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, March 1997. 361 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 362 (ICE): A Protocol for Network Address Translator (NAT) 363 Traversal for Offer/Answer Protocols", RFC 5245, April 364 2010. 366 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 367 Iyengar, "Architectural Guidelines for Multipath TCP 368 Development", RFC 6182, March 2011. 370 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 371 "Default Address Selection for Internet Protocol Version 6 372 (IPv6)", RFC 6724, September 2012. 374 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 375 "TCP Extensions for Multipath Operation with Multiple 376 Addresses", RFC 6824, January 2013. 378 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 379 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 380 2013. 382 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 383 Interface Considerations", RFC 6897, March 2013. 385 10.2. Informative References 387 [I-D.deng-mif-api-session-continuity-guide] 388 Deng, H., Krishnan, S., Lemon, T., and M. Wasserman, 389 "Guide for application developers on session continuity by 390 using MIF API", draft-deng-mif-api-session-continuity- 391 guide-03 (work in progress), October 2012. 393 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 394 Translation", RFC 6296, June 2011. 396 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 397 Congestion Control for Multipath Transport Protocols", RFC 398 6356, October 2011. 400 Authors' Addresses 402 Dan Wing 403 Cisco Systems, Inc. 404 170 West Tasman Drive 405 San Jose, California 95134 406 USA 408 Email: dwing@cisco.com 409 Ram Mohan Ravindranath 410 Cisco Systems, Inc. 411 Cessna Business Park, 412 Kadabeesanahalli Village, Varthur Hobli, 413 Sarjapur-Marathahalli Outer Ring Road 414 Bangalore, Karnataka 560103 415 India 417 Email: rmohanr@cisco.com 419 Tirumaleswar Reddy 420 Cisco Systems, Inc. 421 Cessna Business Park, Varthur Hobli 422 Sarjapur Marathalli Outer Ring Road 423 Bangalore, Karnataka 560103 424 India 426 Email: tireddy@cisco.com 428 Alan Ford 429 Unaffiliated 431 Email: alan.ford@gmail.com 433 Reinaldo Penno 434 Cisco Systems, Inc. 435 170 West Tasman Drive 436 San Jose 95134 437 USA 439 Email: repenno@cisco.com