idnits 2.17.1 draft-ietf-mif-happy-eyeballs-extension-03.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 368: '... 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 (August 28, 2013) is 3887 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Scenario' is mentioned on line 169, but not defined == Missing Reference: 'Problem' is mentioned on line 174, but not defined == Missing Reference: 'Workaround' is mentioned on line 180, but not defined ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-05) exists of draft-anipko-mif-mpvd-arch-02 == Outdated reference: A later version (-05) exists of draft-ietf-mif-api-extension-03 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: March 01, 2014 Consultant 6 D. Wing 7 A. Yourtchenko 8 Cisco Systems, Inc. 9 August 28, 2013 11 Happy Eyeballs Extension for Multiple Interfaces 12 draft-ietf-mif-happy-eyeballs-extension-03 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 March 01, 2014. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Happiness Parameters . . . . . . . . . . . . . . . . . . . . 4 60 4. HE Behaviour in MIF . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. First Step, Filter . . . . . . . . . . . . . . . . . . . 6 62 4.2. Second Step, Sort . . . . . . . . . . . . . . . . . . . . 6 63 5. Implementation Framework . . . . . . . . . . . . . . . . . . 7 64 6. Additional Considerations . . . . . . . . . . . . . . . . . . 8 65 6.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.2. Fallback Timeout . . . . . . . . . . . . . . . . . . . . 8 67 6.3. DNS Selections . . . . . . . . . . . . . . . . . . . . . 9 68 6.4. Flow Continuity . . . . . . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 10.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 In multiple interface context, the problems raised by hosts with 80 multiple interfaces have been discussed. The MIF problem 81 statement[RFC6418] described the various issues when using a wrong 82 domain selection on a MIF node. Happy Eyeballs (HE) [RFC6555] 83 described how a dual-stack client can determine the functioning path 84 to a dual-stack server. It's using stateful algorithm to help 85 applications quickly determine if IPv6 or IPv4 is the most fast path 86 to connect a server. That is a good method to achieve smart path 87 selection. However, the assumption is a single-homed context. The 88 interaction with multiple interfaces is deferred for further study. 90 [I-D.anipko-mif-mpvd-arch] has proposed a multiple provisioning 91 domain architecture. This memo has been proposed to extend happy 92 eyeballs algorithm to fit into the multiple interfaces context. 93 Several additional considerations have been elaborated to analyze the 94 user demands and initiate HE-MIF connections. It allows a node with 95 multiple interfaces picking a fast flow path. 97 2. Problem Statement 99 The section enumerates several concrete use cases in existing 100 networks. 102 Case 1: WiFi is broken 104 o [Scenario] A MIF node has both 3G and WIFI interface. When the 105 node enters a WiFi area, a common practice would always prefer 106 WiFi because it' cheap and fast-speed normally. 108 o [Problem] User assumes the wifi is working, because the node 109 already got IP address from WiFi. However, he can't run 110 applications due to Internet connectivity being unavailable. This 111 may be an authentication required coming into play, or unstable 112 Layer 2 conditions. In order to figure out the problems, users 113 have to turn off the WiFi manually. 115 o [Workaround] Users can indicate their desire with some setting on 116 the phone. For instance, they may prefer to wait a little bit of 117 time but not forever. After the timer is expired, users would 118 finally give up the WiFi path and try to establish connection over 119 3G path. Users may won't want the wait time too short, because 120 the 3G path for most people is more expensive than wifi path. 122 Case 2: VPN (Virtual Private Network) scenario 124 o [Scenario] In some cases, a node has multiple interface because of 125 VPN. Users would only have interests to connect a corporate 126 network inside VPN. While, connecting to Internet would work 127 outside the VPN. 129 o [Problem] That is normally a implementation consideration that 130 unmanaged interface may be considered less trustworthy than 131 managed. It results in trusted interfaces having the highest 132 priority. This setting may steer all traffic to VPN interface. 133 When this is a traffic heading to a corporate site, everything is 134 fine. But sometimes, the connections out to Internet sites may 135 suffer from long-distance path delays. 137 o [Workaround] It's desirable if routing could be bound to each 138 interface. However, a node following weak host model[RFC1122] 139 takes routing tables as node-scoped. Some sophisticated VPN 140 softwares may configure a specific route setting on each interface 141 to dispatch traffic in a predetermined network environment. As an 142 alternative, It may be useful to perform parallel IP connectivity 143 checks before selecting an interface. Consequently, the fastest 144 interface would be picked up automatically. 146 Case 3: 3G/LTE tethering scenario 148 o [Scenario] Many mobile phones are equipped with software to offer 149 tethered Internet access. It shares their Internet connection 150 with another Internet-capable mobile phone or other devices over 151 Wi-Fi. 153 o [Problem] The WiFi link that tethered phone see is not free WiFi 154 link, i.e. it might be 3G backhaul. The policy of "always WiFi" 155 leads to all traffic being sent over the tethering WiFi. Usually, 156 such tethering WiFi link puts sharing limitation to access nodes. 157 It could cause contention on both that WiFi link and the backhaul 158 3G link, while it be higher cost than going on the 3G that is 159 built in the handset. 161 o [Workaround] To solve that, it is necessary for the node to be 162 aware of not only the link layer information, but also services 163 information, like billable or free. That could help to facilitate 164 the execution of the algorithm. Same concern has been documented 165 in Section 4.4 of [RFC6418]) 167 Case 4: Policy Conflict 169 o [Scenario] A node has WiFi and 3G access simultaneously. In 170 mobile network, IPv6-only may be preferable since IPv6 has the 171 potential to be simpler than dual-stack. WiFi access still remain 172 on IPv4. 174 o [Problem] The problem is caused by policy confliction. The 175 transition to IPv6 is likely to encourage IPv6 and prefer 176 IPv6[RFC6724]. If the 3G path has IPv6 on it and the WiFi does 177 not, a suboptimal interface might be chosen from the cost saving 178 perspective. 180 o [Workaround] Users interests should be well understood and 181 considered before interface selection. The different 182 preconditions may impact subsequent behaviors. Users concern 183 about high-reliability or high-speed or less-cost should make 184 different choice. A flexible mechanism should be provided allow 185 to make smart decision. 187 3. Happiness Parameters 189 To solve the problems, this section provides the design proposal for 190 HE-MIF. Two sets of "Happiness" parameters have been defined. It 191 serves upper applications and initiates HE-MIF connections to below 192 level API subsequently. Going through the process, MIF nodes could 193 pick an appropriate interface which would correspond to user demands. 195 The two sets of "Happiness" parameters are called Hard set and Soft 196 set respectively. 198 o Hard set: It contains parameters which have mandatory indications 199 that interface behaviour should comply with. This might provide 200 an interface for applications constraints or delivering operator's 201 policies. Basically, parameters in Hard set should be easy-to-use 202 and easy-to-understand. The potential users would directly use 203 those. When several hard parameters were conflicted, user's 204 preference should override. 206 * User's preference: users would express preferences which may 207 not have a formally technical language , like "No 3G while 208 roaming", "Only use free WiFi", etc. 210 * Operator policies: operators would deliver the customized 211 policies in particular network environments due to geo-location 212 or services regulation considerations. One example in 3GPP 213 network is that operator could deliver policies from access 214 network discovery and selection function (ANDSF). 216 o Soft set: It's a factor contributing to the best path. The 217 following is considered as for the justification. 219 * Next hop: [RFC4191] allows configuration of specific routes to 220 a destination. 222 * DNS selection: [RFC6731] could configure nodes with information 223 to indicate DNS server address for a particular namespace. 225 * Source address selection: the information provided by [RFC6724] 226 would be considered. 228 * Other factors: There is a common practice may impact interface 229 selection, e.g. WiFi is preferable. Such conventional 230 experiences should also be considered. 232 4. HE Behaviour in MIF 234 Corresponding to the two sets of parameters, a HE-MIF node may take a 235 two-step approach. One is to do "hard" decision to synthesize 236 policies from different actors (e.g., users and network operator). 237 In a nutshell, that is a filter which will exclude the interfaces 238 from any further consideration. The second is to adjust how we make 239 a connection on multiple interfaces after the filter. It's a sorting 240 behaviour. In the multiple provisioning domain architecture, 241 Provisioning Domain ( PVD) selection is performed based on "hard" and 242 "soft" inputs. Connections intend to be initiated on the resultant 243 PVDs in parallel. Those two steps are described as following sub- 244 sections. It should be noted that HE-MIF doesn't prescribe such two- 245 step model. It will be very specific to particular cases and 246 implementations. For example, if one interface or PVD is left after 247 the first step, the process would be closed. 249 4.1. First Step, Filter 251 One goal of filter is to reconcile multiple selection policies from 252 users or operators. Afterwards, the merged demands would be mapped 253 to a set of candidate interfaces, which is judged as qualified. 255 Decision on reconciliation of different policies will depend very 256 much on the deployment scenario. An implementation may not be able 257 to determine priority for each policies without explicit 258 configuration provided by users or administrator. For example, an 259 implementation may by default always prefer the WiFi due to cost 260 saving consideration. Whereas, users may dedicatedly prefer 3G 261 interface to seek high-reliability or security benefits even to 262 actively turn off WiFi interface. The decision on mergence of 263 policies may be made by implementations, by node administrators, even 264 by other standards investigating customer behaviour. However, it's 265 worth to note that a demand from users should be normally considered 266 higher priority than from other actors. 268 The merged policies would serve as a filter principle doing iterate 269 across the list of all known interfaces. Qualified interface would 270 be selected to sort processing at next step. 272 4.2. Second Step, Sort 274 Sort process would guarantee "best" interface selection with fallback 275 capacities. As soon as a node connects to a network at bootstrap or 276 changes to a different network, network connectivity status probes 277 have been performed in some existing implementations, e.g. Windows 278 Vista, Windows 7, Windows Server 2008 and iOS. In the process, a 279 pre-configured URL have been connected to examine a certain answer. 280 If anything is abnormal, it assumes there is a proxy on the path. 281 This status detection is recommended to be used in HE-MIF to detect 282 DNS interception or HTTP proxy that forces a login or a click- 283 through. The unexamined interfaces should be accounted as 284 "unconnected" . Those interfaces should not join the sort process. 285 For a PVD-aware node, it could instinctively avoid the mismatch of 286 provisionning information. Those status detection behaviors may not 287 be applied to such node. 289 Two phases normally are involved in a sort process, i.e. name 290 resolving and data session establishing. Parameters in soft set 291 should considered at this stage. 293 When the node initiates name requests, it should follow the 294 instruction in [RFC6731]if DNS server selection DHCP option is 295 provided. Otherwise, DNS queries would be sent out on multiple 296 interfaces on relevant PVDs in parallel. More discussions of DNS 297 selection in HE-MIF are elaborated at Section 6.3. 299 Once a peer address was resolved, a connection would be intended to 300 setup. Heading to a destination, a particular interface on relevant 301 PVDs may comply with the configuration of soft parameters , e.g. next 302 hop[RFC4191] , source address selection[RFC6724] or a common 303 practice. A particular interface should be treated with higher 304 priority compared to others. And, it should be choose to initiate 305 the connection in advance. This could avoid thrashing the network, 306 by not (always) making simultaneous connection attempts on multiple 307 interfaces. After making a connection attempt on the preferred 308 interface and failing to establish a connection within a certain time 309 period (see Section 6.2), a HE-MIF implementation will decide to 310 initiate connection attempt using rest of interfaces in parallel. 311 This fallback consideration may make subsequent connection attempts 312 successful on non-preferable interface. 314 The node would cache information regarding the outcome of each 315 connection attempt. Cache entries would be flushed periodically. A 316 system-defined timeout may take place to age the state. Maximum on 317 the order of 10 minutes defined in [RFC6555] is recommended to keep 318 the interface state changes synchronizing with IP filmily states. So 319 long as new connections are being attempted by the MIF-node, such an 320 implementation should occasionally make connection attempts using the 321 soft-parameter's preferred interface, as it may have become 322 functional again. 324 If there are no specific soft-parameters provided, all selected 325 interface on relevant PVDs should be equally treated. The 326 connections would initiate on several interface simultaneously. The 327 goal here is to provide fast connection for users, by quickly 328 attempting to connect using one of interfaces. Afterwards, the node 329 would do the same caching and flushing process as described above. 331 5. Implementation Framework 333 The simplest way for the implementation is within the application 334 itself. The mechanism described in the document would not require 335 any specific support from the operating system beyond the commonly 336 available APIs that provide transport service. It could also be 337 implemented as high-level API approach, linking to MIF-API 338 [I-D.ietf-mif-api-extension]. A number of enhancements could be 339 added, making the use of the high-level APIs much more productive in 340 building applications. 342 6. Additional Considerations 344 6.1. Usage Scope 346 Connection-oriented transports (e.g., TCP, SCTP) could be directly 347 applied as scoped in [RFC6555]. For connectionless transport 348 protocols (e.g., UDP), it was also described "a similar mechanism can 349 be used if the application has request/ response semantics (e.g., as 350 done by Interactive Connectivity Establishment (ICE) to select a 351 working IPv6 or IPv4 media path[RFC6157])." 353 6.2. Fallback Timeout 355 When the preferred interface was failed, HE-MIF would trigger 356 fallback process to start connection initiation on several candidate 357 interfaces. It should set a reasonable wait time to comfort user 358 experiences. Aggressive timeouts may achieve quick interface 359 handover, but at the cost of traffic that may be chargeable on 360 certain networks. E.g. the handover from WiFi to 3G would bring a 361 bill to customers. Considering the reasons, it is recommended to 362 prioritize the input from users(e.g. real customers or applications) 363 through UI(user interface). For default-setting on a system, a hard 364 error[RFC1122] in replied ICMP could serve as a trigger for the 365 fallback process. When the ICMP soft error is present or non- 366 response was received, it's recommended that the timeout should be 367 large enough to allow connection retransmission. [RFC1122] states 368 that such timer MUST be at least 3 minutes to provide TCP 369 retransmission. Several minutes delay may not inappropriate for user 370 experiences. A widespread practice[RFC5461] sets 75 seconds to 371 optimize connection process. 373 More optimal timer may be expected. The particular setting will be 374 very specific to implementations and cases. The memo didn't try to 375 provide a concrete value due to following concerns. 377 o RTT(Round-Trip Time) on different interfaces may vary quite a lot. 378 A particular value of timeout may not accurately help to make a 379 decision that this interface doesn't work at all. On the 380 contrary, it may cause a misjudgment on a interface, which is not 381 very fast. In order to compensate the issues, the timeout setting 382 based on past experiences of a particular interface may help to 383 make a fair decision. Whereas, it's going beyond the capability 384 of Happy Eyeballs [RFC6555]. Therefore, it's superior to leave it 385 to a particular implementation. 387 o In some cases, fast interface may not be treated as "best". For 388 example, a interface could be evaluated in the principle of 389 bandwidth-delay, termed "Bandwidth-Delay-Product ". Happy 390 Eyeballs measures only connection speed. That is, how quickly a 391 TCP connection is established . It does not measure bandwidth. If 392 the fallback has to take various factors into account and make 393 balanced decision, it's better to resort to a specific context and 394 implementation. 396 6.3. DNS Selections 398 In the sort process, HE-MIF prioritizes [RFC6731]inputs to select a 399 proper server. [RFC6731]could help to address following two cases 400 that HE-MIF failed to address. 402 o A DNS answer may be only valid on a specific provisioning domain, 403 but HE-MIF may not be aware of that mapping because DNS reply may 404 not be kept with the provisioning from which the answer comes. 405 The situation may become worse if asking internal name with public 406 address response or asking public name with private address 407 answers. 409 o Some FQDNs can be resolvable only by sending queries to the right 410 server (e.g., intranet services). Otherwise, a response with 411 NXDOMAIN is replied. HE-MIF treats the DNS answer with fast 412 response as optimal only if the record is valid. That may cause 413 messy for data connections, since NXDOMAIN doesn't provide useful 414 information. 416 By doing HE-MIF, it can help to solve the issues of DNS interception 417 with captive portal. The DNS server modified and replied the answer 418 with the IP address of captive portal rather than the intended 419 destination address. In those cases, TCP connection may succeed, but 420 Internet connectivity is not available. It results in lack of 421 service unless user has authenticated. HE-MIF recommended using 422 network connectivity status probes to examine a pre-configured URL 423 for detecting DNS interception on the path (see more in Section 4.2). 424 The node will be able to automatically rely upon other interfaces to 425 select right DNS servers by excluding the unexamined interfaces. 427 It should be noticed that both [RFC6731]and HE-MIF can't fully solve 428 the problems of DNS resolution issues, which was described in 429 Section 2.3 of [RFC6731]. In order to handle the issues, a MIF-node 430 should have PVD-aware capability to explicitly differentiate various 431 provisioning domains. 433 6.4. Flow Continuity 435 Interface changing should only happen at the beginning of new session 436 in order to keep flow continuity for ongoing TCP session. Dynamic 437 movement of traffic flows are beyond the scope of this document. 439 7. IANA Considerations 441 This memo includes no request to IANA. 443 8. Security Considerations 445 The security consideration is following the statement in [RFC6555]and 446 [RFC6418]. 448 9. Acknowledgements 450 The authors would like to thank Margaret Wasserman, Hui Deng, Erik 451 Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon 452 Perreault, Zhen Cao, Dmitry Anipko and Ted Lemon for their helpful 453 comments. 455 10. References 457 10.1. Normative References 459 [RFC1122] Braden, R., "Requirements for Internet Hosts - 460 Communication Layers", STD 3, RFC 1122, October 1989. 462 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 463 More-Specific Routes", RFC 4191, November 2005. 465 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 466 Dual-Stack Hosts", RFC 6555, April 2012. 468 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 469 "Default Address Selection for Internet Protocol Version 6 470 (IPv6)", RFC 6724, September 2012. 472 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 473 Recursive DNS Server Selection for Multi-Interfaced 474 Nodes", RFC 6731, December 2012. 476 10.2. Informative References 478 [I-D.anipko-mif-mpvd-arch] 479 Anipko, D., "Multiple Provisioning Domain Architecture", 480 draft-anipko-mif-mpvd-arch-02 (work in progress), July 481 2013. 483 [I-D.ietf-mif-api-extension] 484 Liu, D., Lemon, T., and Z. Cao, "MIF API consideration", 485 draft-ietf-mif-api-extension-03 (work in progress), 486 November 2012. 488 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 489 February 2009. 491 [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 492 Transition in the Session Initiation Protocol (SIP)", RFC 493 6157, April 2011. 495 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 496 Provisioning Domains Problem Statement", RFC 6418, 497 November 2011. 499 Authors' Addresses 501 Gang Chen 502 China Mobile 503 53A,Xibianmennei Ave., 504 Xuanwu District, 505 Beijing 100053 506 China 508 Email: phdgang@gmail.com 509 Carl Williams 510 Consultant 511 El Camino Real 512 Palo Alto, CA 94306 513 USA 515 Email: carlw@mcsr-labs.org 517 Dan Wing 518 Cisco Systems, Inc. 519 170 West Tasman Drive 520 San Jose, CA 95134 521 USA 523 Email: dwing@cisco.com 525 Andrew Yourtchenko 526 Cisco Systems, Inc. 527 De Kleetlaan, 7 528 Diegem B-1831 529 Belgium 531 Email: ayourtch@cisco.com