idnits 2.17.1 draft-ietf-mif-happy-eyeballs-extension-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 : ---------------------------------------------------------------------------- ** 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 349: '... that such timer MUST be at least 3 mi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4194 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Scenario' is mentioned on line 166, but not defined == Missing Reference: 'Problem' is mentioned on line 171, but not defined == Missing Reference: 'Workaround' is mentioned on line 177, but not defined == Unused Reference: 'I-D.ietf-mif-problem-statement' is defined on line 433, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-05) exists of draft-ietf-mif-api-extension-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Chen 3 Internet-Draft China Mobile 4 Intended status: Informational C. Williams 5 Expires: April 25, 2013 Consultant 6 D. Wing 7 A. Yourtchenko 8 Cisco Systems, Inc. 9 October 22, 2012 11 Happy Eyeballs Extension for Multiple Interfaces 12 draft-ietf-mif-happy-eyeballs-extension-01 14 Abstract 16 Currently the interface selection in multi-interface environment is 17 exclusive - only one interface can be used at the time, frequently 18 needing manual intervention. Happy Eyeballs in MIF would make the 19 selection process smoother by using the connectivity checks over a 20 pre-filtered interfaces according to defined policy. This would 21 choose "best" interface with an automatic fallback. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 25, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Happiness Parameters . . . . . . . . . . . . . . . . . . . . . 5 60 4. HE Behaviour in MIF . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. First Step, Filter . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Second Step, Sort . . . . . . . . . . . . . . . . . . . . 7 63 5. Implementation Framework . . . . . . . . . . . . . . . . . . . 8 64 6. Additional Considerations . . . . . . . . . . . . . . . . . . 8 65 6.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.2. Fallback Timeout . . . . . . . . . . . . . . . . . . . . . 8 67 6.3. Flow Continuity . . . . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 In multiple interface context, the problems raised by hosts with 79 multiple interfaces have been discussed. The MIF problem 80 statement[RFC6418] described the various issues when using a wrong 81 domain selection on a MIF node. Happy Eyeballs (HE) [RFC6555] 82 described how a dual-stack client can determine the functioning path 83 to a dual-stack server. It's using stateful algorithm to help 84 applications quickly determine if IPv6 or IPv4 is the most fast path 85 to connect a server. That is a good method to achieve smart path 86 selection. However, the assumption is a single-homed context. The 87 interaction with multiple interfaces is deferred for further study. 89 This memo has been proposed to extend happy eyeballs algorithm to fit 90 into multiple interfaces context. Several additional considerations 91 have been elaborated to analyze the user demands and initiate HE-MIF 92 connections. It allows a node with multiple interfaces picking a 93 fast flow path. 95 2. Problem Statement 97 The section enumerates several concrete use cases in existing 98 networks. 100 Case 1: WiFi is broken 102 o [Scenario] A MIF node has both 3G and WIFI interface. When the 103 node enters a WiFi area, a common practice would always prefer 104 WiFi because it' cheap and fast-speed normally. 106 o [Problem] User assumes the wifi is working, because the node 107 already got IP address from WiFi. However, he can't run 108 applications due to Internet connectivity being unavailable. This 109 may be an authentication required coming into play, or unstable 110 Layer 2 conditions. In order to figure out the problems, users 111 have to turn off the WiFi manually. 113 o [Workaround] Users can indicate their desire with some setting on 114 the phone. For instance, they may prefer to wait a little bit of 115 time but not forever. After the timer is expired, users would 116 finally give up the WiFi path and try to establish connection over 117 3G path. Users may won't want the wait time too short, because 118 the 3G path for most people is more expensive than wifi path. 120 Case 2: VPN (Virtual Private Network) scenario 121 o [Scenario] In some cases, a node has multiple interface because of 122 VPN. Users would only have interests to connect a corporate 123 network inside VPN. While, connecting to Internet would work 124 outside the VPN. 126 o [Problem] That is normally a implementation consideration that 127 unmanaged interface may be considered less trustworthy than 128 managed. It results in trusted interfaces having the highest 129 priority. This setting may steer all traffic to VPN interface. 130 When this is a traffic heading to a corporate site, everything is 131 fine. But sometimes, the connections out to Internet sites may 132 suffer from long-distance path delays. 134 o [Workaround] It's desirable if routing could be bound to each 135 interface. However, a node following weak host model[RFC1122] 136 takes routing tables as node-scoped. Some sophisticated VPN 137 softwares may configure a specific route setting on each interface 138 to dispatch traffic in a predetermined network environment. As an 139 alternative, It may be useful to perform parallel IP connectivity 140 checks before selecting an interface. Consequently, the fastest 141 interface would be picked up automatically. 143 Case 3: 3G/LTE tethering scenario 145 o [Scenario] Many mobile phones are equipped with software to offer 146 tethered Internet access. It shares their Internet connection 147 with another Internet-capable mobile phone or other devices over 148 Wi-Fi. 150 o [Problem] The WiFi link that tethered phone see is not free WiFi 151 link, i.e. it might be 3G backhaul. The policy of "always WiFi" 152 leads to all traffic being sent over the tethering WiFi. Usually, 153 such tethering WiFi link puts sharing limitation to access nodes. 154 It could cause contention on both that WiFi link and the backhaul 155 3G link, while it be higher cost than going on the 3G that is 156 built in the handset. 158 o [Workaround] To solve that, it is necessary for the node to be 159 aware of not only the link layer information, but also services 160 information, like billable or free. That could help to facilitate 161 the execution of the algorithm. Same concern has been documented 162 in Section 4.4 of [RFC6418]) 164 Case 4: Policy Conflict 166 o [Scenario] A node has WiFi and 3G access simultaneously. In 167 mobile network, IPv6-only may be preferable since IPv6 has the 168 potential to be simpler than dual-stack. WiFi access still remain 169 on IPv4. 171 o [Problem] The problem is caused by policy confliction. The 172 transition to IPv6 is likely to encourage IPv6 and prefer 173 IPv6[RFC6724]. If the 3G path has IPv6 on it and the WiFi does 174 not, a suboptimal interface might be chosen from the cost saving 175 perspective. 177 o [Workaround] Users interests should be well understood and 178 considered before interface selection. The different 179 preconditions may impact subsequent behaviors. Users concern 180 about high-reliability or high-speed or less-cost should make 181 different choice. A flexible mechanism should be provided allow 182 to make smart decision. 184 3. Happiness Parameters 186 To solve the problems, this section provides the design proposal for 187 HE-MIF. Two sets of "Happiness" parameters have been defined. It 188 serves upper applications and initiates HE-MIF connections to below 189 level API subsequently. Going through the process, MIF nodes could 190 pick an appropriate interface which would correspond to user demands. 191 The two sets of "Happiness" parameters are called Hard set and Soft 192 set respectively. 194 o Hard set: It contains parameters which have mandatory indications 195 that interface behaviour should comply with. This might provide 196 an interface for applications constraints or delivering operator's 197 policies. Basically, parameters in Hard set should be easy-to-use 198 and easy-to-understand. The potential users would directly use 199 those. When several hard parameters were conflicted, user's 200 preference should override. 202 * User's preference: users would express preferences which may 203 not have a formally technical language , like "No 3G while 204 roaming", "Only use free WiFi", etc. 206 * Operator policies: operators would deliver the customized 207 policies in particular network environments due to geo-location 208 or services regulation considerations. One example in 3GPP 209 network is that operator could deliver policies from access 210 network discovery and selection function (ANDSF). 212 o Soft set: It's a factor contributing to the best path. The 213 following is considered as for the justification. 215 * Next hop: [RFC4191] and DHCPv6 Route Option 216 [I-D.ietf-mif-dhcpv6-route-option] allow configuration of 217 specific routes to a destination. 219 * DNS selection: [I-D.ietf-mif-dns-server-selection] could 220 configure nodes with information to indicate DNS server address 221 for a particular namespace. 223 * Source address selection: the information provided by [RFC6724] 224 would be considered. 226 * Other factors: There is a common practice may impact interface 227 selection, e.g. WiFi is preferable. Such conventional 228 experiences should also be considered. 230 4. HE Behaviour in MIF 232 Corresponding to the two sets of parameters, an HE-MIF node may take 233 a two-step approach. One is to do "hard" decision to synthesize 234 policies from different actors (e.g., users and network operator). 235 In a nutshell, that is a filter which will exclude the interfaces 236 from any further consideration. The second is to adjust how we make 237 a connection on multiple interfaces after the filter. It's a sorting 238 behaviour. Those two things are described as following sub-sections. 239 It should be noted that HE-MIF doesn't prescribe such two-step model. 240 It will be very specific to particular cases and implementations. 241 For example, if one interface is left after the first step, the 242 process would be closed. 244 4.1. First Step, Filter 246 One goal of filter is to reconcile multiple selection policies from 247 users or operators. Afterwards, the merged demands would be mapped 248 to a set of candidate interfaces, which is judged as qualified. 250 Decision on reconciliation of different policies will depend very 251 much on the deployment scenario. An implementation may not be able 252 to determine priority for each policies without explicit 253 configuration provided by users or administrator. For example, an 254 implementation may by default always prefer the WiFi due to cost 255 saving consideration. Whereas, users may dedicatedly prefer 3G 256 interface to seek high-reliability or security benefits even to 257 actively turn off WiFi interface. The decision on mergence of 258 policies may be made by implementations, by node administrators, even 259 by other standards investigating customer behaviour. However, it's 260 worth to note that a demand from users should be normally considered 261 higher priority than from other actors. 263 The merged policies would serve as a filter principle doing iterate 264 across the list of all known interfaces. Qualified interface would 265 be selected to sort processing at next step. 267 4.2. Second Step, Sort 269 Sort process would guarantee "best" interface selection with fallback 270 capacities. Two phases normally are involved in a whole session, 271 i.e. name resolving and data session establishing. Parameters in 272 soft set should considered at this stage. 274 When the node initiates name requests, it should follow the 275 instruction in [I-D.ietf-mif-dns-server-selection]if DNS server 276 selection DHCP option is provided. Otherwise, several alternative 277 behaviour for DNS server selection described in Appendix A of 278 [I-D.ietf-mif-dns-server-selection]maybe performed. 280 Once a peer address was resolved, a connection would be intended to 281 setup. Heading to a destination, a particular interface may comply 282 with the configuration of soft parameters , e.g. next hop[RFC4191] 283 [I-D.ietf-mif-dhcpv6-route-option], source address selection[RFC6724] 284 or a common practice. A particular interface should be treated with 285 higher priority compared to others. And, it should be choose to 286 initiate the connection in advance. This could avoid thrashing the 287 network, by not (always) making simultaneous connection attempts on 288 multiple interfaces. After making a connection attempt on the 289 preferred interface and failing to establish a connection within a 290 certain time period (see Section 6.2), a HE-MIF implementation will 291 decide to initiate connection attempt using rest of interfaces in 292 parallel. This fallback consideration may make subsequent connection 293 attempts successful on non-preferable interface. 295 The node would cache information regarding the outcome of each 296 connection attempt. Cache entries would be flushed periodically. A 297 system-defined timeout may take place to age the state. Maximum on 298 the order of 10 minutes defined in [RFC6555] is recommended to keep 299 the interface state changes synchronizing with IP filmily states. So 300 long as new connections are being attempted by the MIF-node, such an 301 implementation should occasionally make connection attempts using the 302 soft-parameter's preferred interface, as it may have become 303 functional again. 305 If there are no specific soft-parameters provided, all interface 306 should be equally treated. The connections would initiate on several 307 interface simultaneously. The goal here is to provide fast 308 connection for users, by quickly attempting to connect using one of 309 interfaces. Afterwards, the node would do the same caching and 310 flushing process as described above. 312 5. Implementation Framework 314 The simplest way for the implementation is within the application 315 itself. The mechanism described in the document would not require 316 any specific support from the operating system beyond the commonly 317 available APIs that provide transport service. It could also be 318 implemented as high-level API approach, linking to MIF-API 319 [I-D.ietf-mif-api-extension]. A number of enhancements could be 320 added, making the use of the high-level APIs much more productive in 321 building applications. 323 6. Additional Considerations 325 6.1. Usage Scope 327 Connection-oriented transports (e.g., TCP, SCTP) could be directly 328 applied as scoped in [RFC6555]. For connectionless transport 329 protocols (e.g., UDP), it was also described "a similar mechanism can 330 be used if the application has request/ response semantics (e.g., as 331 done by Interactive Connectivity Establishment (ICE) to select a 332 working IPv6 or IPv4 media path[RFC6157])." 334 6.2. Fallback Timeout 336 When the preferred interface was failed, HE-MIF would trigger 337 fallback process to start connection initiation on several candidate 338 interfaces. It should set a reasonable wait time to comfort user 339 experiences. Aggressive timeouts may achieve quick interface 340 handover, but at the cost of traffic that may be chargeable on 341 certain networks. E.g. the handover from WiFi to 3G would bring a 342 bill to customers. Considering the reasons, it is recommended to 343 prioritize the input from users(e.g. real customers or applications) 344 through UI(user interface). For default-setting on a system, a hard 345 error[RFC1122] in replied ICMP could serve as a trigger for the 346 fallback process. When the ICMP soft error is present or non- 347 response was received, it's recommended that the timeout should be 348 large enough to allow connection retransmission. [RFC1122] states 349 that such timer MUST be at least 3 minutes to provide TCP 350 retransmission. Several minutes delay may not inappropriate for user 351 experiences. A widespread practice[RFC5461] sets 75 seconds to 352 optimize connection process. 354 More optimal timer may be expected. The particular setting will be 355 very specific to implementations and cases. The memo didn't try to 356 provide a concrete value due to following concerns. 358 o RTT(Round-Trip Time) on different interfaces may vary quite a lot. 359 A particular value of timeout may not accurately help to make a 360 decision that this interface doesn't work at all. On the 361 contrary, it may cause a misjudgment on a interface, which is not 362 very fast. In order to compensate the issues, the timeout setting 363 based on past experiences of a particular interface may help to 364 make a fair decision. Whereas, it's going beyond the capability 365 of Happy Eyeballs [RFC6555]. Therefore, it's superior to leave it 366 to a particular implementation. 368 o In some cases, fast interface may not be treated as "best". For 369 example, a interface could be evaluated in the principle of 370 bandwidth-delay, termed "Bandwidth-Delay-Product ". Happy 371 Eyeballs measures only connection speed. That is, how quickly a 372 TCP connection is established . It does not measure bandwidth. 373 If the fallback has to take various factors into account and make 374 balanced decision, it's better to resort to a specific context and 375 implementation. 377 6.3. Flow Continuity 379 Interface changing should only happen at the beginning of new session 380 in order to keep flow continuity for ongoing TCP session. Dynamic 381 movement of traffic flows are beyond the scope of this document. 383 7. IANA Considerations 385 This memo includes no request to IANA. 387 8. Security Considerations 389 The security consideration is following the statement in [RFC6555]and 390 [RFC6418]. 392 9. Acknowledgements 394 The authors would like to thank Margaret Wasserman, Hui Deng, Erik 395 Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon 396 Perreault, Zhen Cao and Dmitry Anipko for their helpful comments. 398 10. References 399 10.1. Normative References 401 [I-D.ietf-mif-dns-server-selection] 402 Savolainen, T., Kato, J., and T. Lemon, "Improved 403 Recursive DNS Server Selection for Multi-Interfaced 404 Nodes", draft-ietf-mif-dns-server-selection-12 (work in 405 progress), August 2012. 407 [RFC1122] Braden, R., "Requirements for Internet Hosts - 408 Communication Layers", STD 3, RFC 1122, October 1989. 410 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 411 More-Specific Routes", RFC 4191, November 2005. 413 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 414 Dual-Stack Hosts", RFC 6555, April 2012. 416 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 417 "Default Address Selection for Internet Protocol Version 6 418 (IPv6)", RFC 6724, September 2012. 420 10.2. Informative References 422 [I-D.ietf-mif-api-extension] 423 Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API 424 consideration", draft-ietf-mif-api-extension-01 (work in 425 progress), July 2012. 427 [I-D.ietf-mif-dhcpv6-route-option] 428 Dec, W., Mrugalski, T., Sun, T., Sarikaya, B., and A. 429 Matsumoto, "DHCPv6 Route Options", 430 draft-ietf-mif-dhcpv6-route-option-05 (work in progress), 431 August 2012. 433 [I-D.ietf-mif-problem-statement] 434 Blanchet, M. and P. Seite, "Multiple Interfaces and 435 Provisioning Domains Problem Statement", 436 draft-ietf-mif-problem-statement-15 (work in progress), 437 May 2011. 439 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 440 February 2009. 442 [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 443 Transition in the Session Initiation Protocol (SIP)", 444 RFC 6157, April 2011. 446 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 447 Provisioning Domains Problem Statement", RFC 6418, 448 November 2011. 450 Authors' Addresses 452 Gang Chen 453 China Mobile 454 53A,Xibianmennei Ave., 455 Xuanwu District, 456 Beijing 100053 457 China 459 Email: phdgang@gmail.com 461 Carl Williams 462 Consultant 463 El Camino Real 464 Palo Alto, CA 94306 465 USA 467 Email: carlw@mcsr-labs.org 469 Dan Wing 470 Cisco Systems, Inc. 471 170 West Tasman Drive 472 San Jose, CA 95134 473 USA 475 Email: dwing@cisco.com 477 Andrew Yourtchenko 478 Cisco Systems, Inc. 479 De Kleetlaan, 7 480 Diegem B-1831 481 Belgium 483 Email: ayourtch@cisco.com