idnits 2.17.1 draft-wr-mptcp-single-homed-06.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 are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 192: '... the client SHOULD create up to n vi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3084 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Winter 3 Internet-Draft M. Faath 4 Intended status: Informational University of Applied Sciences Augsburg 5 Expires: April 21, 2016 A. Ripke 6 NEC Laboratories Europe 7 October 19, 2015 9 Multipath TCP Support for Single-homed End-systems 10 draft-wr-mptcp-single-homed-06 12 Abstract 14 Multipath TCP relies on the existence of multiple paths between end- 15 systems. These are typically provided by using different IP 16 addresses obtained by different ISPs at the end-systems. While this 17 scenario is certainly becoming increasingly a reality (e.g. mobile 18 devices), currently most end-systems are single-homed (e.g. desktop 19 PCs in an enterprise). It seems also likely that a lot of network 20 sites will insist on having all traffic pass a single network element 21 (e.g. for security reasons) before traffic is split across multiple 22 paths. This memo therefore describes mechanisms to make multiple 23 paths available to multipath TCP-capable end-systems that are not 24 available directly at the end-systems but somewhere within the 25 network. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 21, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Approaches to Use Multiple Paths in the Network . . . . . . . 3 63 2.1. Exposing Multiple Paths Through End-host Auto- 64 configuration . . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. Heuristic Use of Multiple Paths . . . . . . . . . . . . . 5 66 3. Other scenarios and extensions . . . . . . . . . . . . . . . 5 67 4. Alternative approaches . . . . . . . . . . . . . . . . . . . 6 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 8.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 The IETF has specified a multipath TCP (MPTCP) architecture and 79 protocol where end-systems operate a modified standard TCP stack 80 which allows packets of the same TCP connection to be sent via 81 different paths to an MPTCP-capable destination ([RFC6824], 82 [RFC6182]). Paths are defined by sets of source and destination IP 83 addresses. Using multiple paths has a number of benefits such as an 84 increased reliability of the transport connection and an effect known 85 as resource pooling [resource_pooling]. Most end-systems today do 86 not have multiple paths/interfaces available in order to make use of 87 multipath TCP, however further within the network multiple paths are 88 the norm rather than the exception. This memo therefore describes 89 ways how these multiple paths in the network could potentially be 90 made available to multipath TCP-capable hosts that are single-homed. 92 In order to illustrate the general mechanism we make use of a simple 93 reference scenario shown in Figure 1. 95 +-------+ 96 | DHCP | 97 +-------+ +----------+ Server| 98 | | | | | 99 | Host +------+ +-------+ 100 | | | +-------+ ISP 1 101 +-------+ +------+ |---------- 102 | Gatew.| 103 | |---------- 104 +-------+ ISP 2 106 Figure 1: Reference Scenario 108 The scenario in Figure 1 depicts e.g. a possible SOHO or enterprise 109 setup where a gateway/router is connected to two ISPs and a DHCP 110 server gives out leases to hosts connected to the local network. 111 Note that both, the gateway and the DHCP server could be on the same 112 device (similar to current home gateway implementations). 114 The host is running a multipath-capable IP stack, however it only has 115 a single interface. The methods described in the following sections 116 will let the host make use of the gateway's two interfaces without 117 requiring modifications to the MPTCP implementation. 119 2. Approaches to Use Multiple Paths in the Network 121 All approaches in this document do not require changes to the wire 122 format of MPTCP and both communicating hosts need to be MPTCP- 123 capable. The benefit this approach has is that a) it has no 124 implications on MPTCP standards, b) it will hopefully encourage the 125 deployment of MPTCP as the number of scenarios where MPTCP brings 126 benefits vastly increases and c) these approaches do not require 127 complex middle-boxes to implement MPTCP-like functionality in the 128 network as other approaches have suggested before. 130 2.1. Exposing Multiple Paths Through End-host Auto-configuration 132 Multipath TCP distinguishes paths by their source and destination IP 133 addresses. Assuming a certain level of path diversity in the 134 Internet, using different source and destination IP addresses for a 135 given subflow of a multipath TCP connection will, with a certain 136 probability, result in different paths taken by packets of different 137 subflows. Even in case subflows share a common bottleneck, the 138 proposed multipath congestion control algorithm [RFC6356] will make 139 sure that multipath TCP will play nicely with regular TCP flows. 141 In order to not require changes to the TCP implementation, we keep 142 the above assumptions multipath TCP makes, i.e. working with 143 different IP addresses to use different paths. Since the end-system 144 is single-homed, all IP addresses are bound to the same physical 145 interface. In our reference scenario in Figure 1, the host would 146 e.g. receive more than one RFC1918 [RFC1918] private IP address from 147 the DHCP server as depicted in Figure 2. 149 Host Gateway 151 +-----------------+ ISP1 152 +--------+ | src. | 153 | virt. | 10.1.2.5 | 10.1.0.0/16 __.+---------- 154 | +---+ | __.--' | 155 | phys. | | | __.--' N | 156 | +----------+.:_ A | 157 | | 10.2.2.6 | `-.._ T | 158 +--------+ | src. `-.._ | ISP2 159 | 10.2.0.0/16 `-..+---------- 160 | | 161 +-----------------+ 163 Figure 2: Gateway internals 165 The gateway that is shown in Figure 2 has received two IP addresses, 166 one from each ISP that it is connected to (ISP1 and ISP2). The NAT 167 that the gateway is implementing needs to "map" each private IP 168 address of the host consistently to a one of the addresses received 169 by the ISPs, i.e. each private IP to a different public IP. Packets 170 sent by the host to the gateway are then routed based on the source 171 address found in the packets as illustrated in the figure. In other 172 words, depending on the source address of the host, the packets will 173 either go through ISP 1 or ISP 2 and TCP will balance the traffic 174 across those two links using its built-in congestion control 175 mechanism. 177 The way the gateway has received its public IP addresses is not 178 relevant. It could be via DHCP, IPCP or static configuration. In 179 order to configure the hosts behind the gateway, we propose to make 180 use of provisioning domains [RFC7556], more specifically one 181 provisioning domain per external gateway interface (the two 182 interfaces to ISP1 and ISP2 in Figure 2). In order to signal to the 183 host, that each provisioning domain will result in a different path 184 towards the Internet, this memo introduces a new DHCP option called 185 EXT_ROUTE, which will be included in each provisioning domain sent by 186 the server. The option value will determine which external interface 187 is used to sent the traffic when using the configuration information 188 present in the respective provisioning domain. 190 Upon receipt of a DHCP offer including multiple provisioning domains, 191 or multiple offers each including one or more provisioning domains, 192 the client SHOULD create up to n virtual interfaces, where n is one 193 less than the number of different EXT_ROUTE option values found in 194 all received provisioning domains. Each virtual interface will 195 contact the DHCP server and will request configuration information 196 for the respective provisioning domains, excluding the configuration 197 of the physical interface. 199 2.2. Heuristic Use of Multiple Paths 201 The auto-configuration mechanism above has the advantage that 202 available paths and information on how to use them are directly sent 203 to the end-host. In other words, there is an explicit signalling of 204 the availability of multiple paths to the end-host. This has the 205 advantage that the host can efficiently use these paths. 207 This method works well when multiple paths are available close to the 208 end-host and means for auto-configuration are available. But that is 209 not always the case. Another method to use different paths in the 210 network without prior knowledge of their existence is to apply 211 heuristics in order to exploit setups where Equal Cost Multi-path 212 [RFC2991], a widely deployed technology [ECMP_DEPLOYMENT], or similar 213 per-flow load-balancing algorithms are employed. 215 The ADD_ADDR option defined in [RFC6824] can be used to advertise the 216 same address but a different port to open another subflow. 217 Additionally, the MP_JOIN option can also be used to open another 218 subflow with the same IP address and e.g. a different source port 219 given that a different address ID is used. This means there are 220 multiple scenarios possible (e.g. either sender-initated or receiver- 221 initiated) where single-homed end-hosts can influence the 5-tuple 222 (source and destination IP addresses and port numbers plus protocol 223 number) which is often used as the basis for per-flow load balancing. 224 Changing the 5-tuple will only with a certain probability result in 225 using a different path unless the load-balancing algorithm that is 226 used is known to the MPTCP implementation (an assumption we cannot 227 generally make). This means that a number of subflows might end up 228 on the same path. Fortunately, the MPTCP congestion control 229 algorithm will make sure that the collection of subflows on that path 230 will not be more agressive than a single TPC flow. 232 3. Other scenarios and extensions 234 The reference scenario is only one conceivable setting. Other 235 scenarios such as DSL broadband customers or mobile phones are 236 conceivable as well. As an example, take the DSL scenario. The home 237 gateway could be provided with multiple IP addresses using extensions 238 to IPCP. The home gateway in turn can then implement the DHCP server 239 and gateway functionality as described before. More scenarios will 240 be described in future versions of this document. 242 4. Alternative approaches 244 One alternative is that a DHCP server always sends n offers, where n 245 is the number of interfaces at the gateway to different ISPs. The 246 client could then accept all or a subset of these offers. This 247 approach seems interesting in environments where there are multiple 248 DHCP servers, one for each ISP connection (think multiple home 249 gateways). However, accepting multiple offers based on a single DHCP 250 request is not standard's compliant behavior (at least for the DHCPv4 251 case). Also, to cater for a scenario that only contains a single 252 DHCP server, server changes are needed in any case. Finally, correct 253 routing is not always guaranteed in these scenarios. 255 An interesting alternative is the use of ECMP at the gateway for load 256 distribution and let MPTCP use different port numbers for subflows. 257 Assuming that ECMP is available at the gateway, this approach would 258 work fine today. The only drawback of the approach is that it 259 involves a little trial and error to find port numbers that actually 260 hash to different paths used by ECMP [RFC2991]. 262 5. Acknowledgements 264 Part of this work was supported by Trilogy (http://www.trilogy- 265 project.org), a research project (ICT-216372) partially funded by the 266 European Community under its Seventh Framework Program. The views 267 expressed here are those of the author(s) only. The European 268 Commission is not liable for any use that may be made of the 269 information in this document. 271 6. IANA Considerations 273 One new DHCP options is required by this version of this document. 275 7. Security Considerations 277 TBD. 279 8. References 281 8.1. Normative References 283 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 284 and E. Lear, "Address Allocation for Private Internets", 285 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 286 . 288 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 289 Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/ 290 RFC2991, November 2000, 291 . 293 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 294 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 295 . 297 8.2. Informative References 299 [ECMP_DEPLOYMENT] 300 Augustin, B., Friedman, T., and R. Teixeira, "Measuring 301 Multipath Routing in the Internet", October 2011, 302 . 304 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 305 Iyengar, "Architectural Guidelines for Multipath TCP 306 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 307 . 309 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 310 Congestion Control for Multipath Transport Protocols", RFC 311 6356, DOI 10.17487/RFC6356, October 2011, 312 . 314 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 315 "TCP Extensions for Multipath Operation with Multiple 316 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 317 . 319 [resource_pooling] 320 Wischik, D., Handley, M., and M. Bagnulo Braun, "The 321 Resource Pooling Principle", October 2008, 322 . 324 Authors' Addresses 325 Rolf Winter 326 University of Applied Sciences Augsburg 327 An der Hochschule 1 328 Augsburg 86161 329 Germany 331 Email: rolf.winter@hs-augsburg.de 333 Michael Faath 334 University of Applied Sciences Augsburg 335 An der Hochschule 1 336 Augsburg 86161 337 Germany 339 Email: michael.faath@hs-augsburg.de 341 Andreas Ripke 342 NEC Laboratories Europe 343 Kurfuersten-Anlage 36 344 Heidelberg 69115 345 Germany 347 Email: andreas.ripke@neclab.eu