idnits 2.17.1 draft-ietf-mif-happy-eyeballs-extension-07.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 323: '... 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 17, 2015) is 3114 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 19, 2016 Consultant 6 D. Wing 7 A. Yourtchenko 8 Cisco Systems, Inc. 9 October 17, 2015 11 Happy Eyeballs Extension for Multiple Interfaces 12 draft-ietf-mif-happy-eyeballs-extension-07 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 the fastest 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 19, 2016. 40 Copyright Notice 42 Copyright (c) 2015 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. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Happiness Parameters . . . . . . . . . . . . . . . . . . . . 3 60 4. HE Behavior in MIF . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. First Step, Filter . . . . . . . . . . . . . . . . . . . 5 62 4.2. Second Step, Sort . . . . . . . . . . . . . . . . . . . . 5 63 5. Implementation Framework . . . . . . . . . . . . . . . . . . 7 64 6. Additional Considerations . . . . . . . . . . . . . . . . . . 7 65 6.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.2. Fallback Timeout . . . . . . . . . . . . . . . . . . . . 7 67 6.3. DNS Selections . . . . . . . . . . . . . . . . . . . . . 8 68 6.4. Flow Continuity . . . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 10.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 [RFC7556] has proposed a multiple provisioning domain architecture. 91 This memo has been proposed to extend happy eyeballs algorithm to fit 92 into the multiple interfaces architecture. Several additional 93 considerations have been elaborated to analyze the user demands and 94 initiate HE-MIF connections. It allows a node with multiple 95 interfaces picking a fast flow path. 97 2. Use Cases 99 The section describes use cases in existing networks. 101 Use Case: WiFi is broken 103 A MIF node has both 3/4G and WiFi interface. When the node enters a 104 WiFi area, a common practice would always prefer WiFi because it' 105 cheap and fast-speed normally. User assumes the WiFi is working, 106 because the node already got IP address from WiFi. However, he can't 107 run applications due to Internet connectivity being unavailable. 108 This may be an authentication required coming into play, or unstable 109 Layer 2 conditions. In order to figure out the problems, users have 110 to turn off the WiFi manually. With HE-MIF, users can indicate their 111 desire with some setting on the phone. For instance, they may prefer 112 to wait a little bit of time but not forever. After the timer is 113 expired, users would finally give up the WiFi path and try to 114 establish connection over 3G path. Users may won't want the wait 115 time too short, because the 3G path for most people is more expensive 116 than WiFi path. 118 Use Case: Policy Conflict 120 A node has WiFi and 3/4G access simultaneously. In mobile network, 121 IPv6-only may be preferable since IPv6 has the potential to be 122 simpler than dual-stack. WiFi access still remains on IPv4. The 123 problem is caused by policy confliction. The transition to IPv6 is 124 likely to encourage IPv6 and prefer IPv6[RFC6724]. If the 3/4G path 125 has IPv6 on it and the WiFi does not, a suboptimal interface might be 126 chosen from the cost saving perspective. With HE-MIF, users 127 interests should be well understood and considered before interface 128 selection. The different preconditions may impact subsequent 129 behaviors. Users concern about high-reliability or high-speed or 130 less-cost should make different choice. A flexible mechanism should 131 be provided allow to make smart decision. 133 3. Happiness Parameters 135 This section provides the design proposal for HE-MIF. Two sets of 136 "Happiness" parameters have been defined. It serves upper 137 applications and initiates HE-MIF connections to below level API 138 subsequently. Going through the process, MIF nodes could pick an 139 appropriate interface which would correspond to user demands. The 140 two sets of "Happiness" parameters are called Hard set and Soft set 141 respectively. 143 o Hard Set: It contains parameters which have mandatory indications 144 that interface behavior should comply with. This might provide an 145 interface for applications constraints or delivering operator's 146 policies. Basically, parameters in Hard set should be easy-to-use 147 and easy-to-understand. The users would directly use those. When 148 several hard parameters were conflicted, user's preference should 149 be prioritized. 151 * User's preference: users would express preferences which may 152 not have a formally technical language , like "No 3G while 153 roaming", "Only use free WiFi", etc. 155 * Operator policy: operators would deliver the customized 156 policies in particular network environments due to geo-location 157 or services regulation considerations. One example in 3GPP 158 network is that operator could deliver policies from access 159 network discovery and selection function (ANDSF). 161 o Soft Set: It contains factors involving in the selection of the 162 fastest path. The following is considered as for the 163 justification. 165 * PVD-ID (Provisioning Domain Identity): PVD-aware node may 166 decide to use one preferred PVD or allow use mulitple PVDs 167 simultanenously for applications. The node behavior should be 168 consistent with MPVD architecture. 170 * Next hop: [RFC4191] allows configuration of specific routes to 171 a destination. 173 * DNS selection: [RFC6731] could configure nodes with information 174 to indicate DNS server address for a particular namespace. 176 * Source address selection: the information provided by [RFC6724] 177 would be considered. 179 * Other factors: There is a common practice may impact interface 180 selection, e.g. WiFi is preferable. Such conventional 181 experiences should also be considered. 183 4. HE Behavior in MIF 185 Corresponding to the two sets of parameters, a HE-MIF node may take a 186 two-steps approach. One is to do "Hard" decision to synthesize 187 policies from different actors (e.g., users and network operator). 188 In a nutshell, that is a filter which will exclude the interfaces 189 from any further consideration. The second is to adjust how we make 190 a connection on multiple interfaces after the filter. It's sorting 191 behavior. In the multiple provisioning domain architecture, a PVD 192 aware node takes connectivity tests as described in Section 5.3 of 194 [RFC7556]. A PVD agnostic node take other parameters in the Soft Set 195 to proceed the sort process. 197 Those two steps are described as following sub-sections. It should 198 be noted that HE-MIF doesn't prescribe such two-step model. It will 199 be very specific to particular cases and implementations. For 200 example, if one interface on a particular PVD is left after the first 201 step, the process would be ceased. 203 4.1. First Step, Filter 205 One goal of filter is to reconcile multiple selection policies from 206 users or operators. Afterwards, the merged demands would be mapped 207 to a set of candidate interfaces, which is judged as qualified. 209 Decision on reconciliation of different policies will depend very 210 much on the deployment scenario. An implementation may not be able 211 to determine priority for each policies without explicit 212 configuration provided by users or administrator. For example, an 213 implementation may by default always prefer the WiFi due to cost 214 saving consideration. Whereas, users may dedicatedly prefer 3/4G 215 interface to seek high-reliability or security benefits even to 216 manually turn off WiFi interface. The decision on mergence of 217 policies may be made by implementations, by node administrators, even 218 by other standards investigating customer behavior. However, it's 219 worth to note that a demand from users should be normally considered 220 higher priority than from other actors. 222 The merged policies would serve as a filter principle doing iterate 223 across the list of all known interfaces. Qualified interface would 224 be selected to sort processing at next step. 226 4.2. Second Step, Sort 228 Sort process guarantees fast interface selection with fallback 229 capacities. As stated in [RFC7556], a PVD-aware node shall perform 230 connectivity test and, only after validation of the PVD, consider 231 using it to serve application connections requests. A common 232 practise is to probe a pre-configured URL to check network 233 connectivity status as soon as a node access a network at bootstrap 234 or changes to different networks, e.g. Windows Vista, Windows 7, 235 Windows Server 2008 and iOS. If anything is abnormal, it assumes 236 there is a proxy on the path. This status detection is recommended 237 to be used in HE-MIF to detect DNS interception or HTTP proxy that 238 forces a login or a click-through. Unexamined PVDs or interfaces 239 should be accounted as "unconnected". It should not join the sort 240 process. 242 Afterwards, two phases normally are involved in a sort process, i.e. 243 name resolving and connection establishment. Parameters in a soft 244 set should considered at this stage. 246 When a node initiates name resolution requests, it should check if 247 there is a matched PVD ID for the destination name. A PVD agnostic 248 node may request DNS server selection DHCP option[RFC6731] for 249 interface selection guidance. Those information may weight a 250 particular interface to be preferred one prior to others sending 251 resolving requests. If the node can't find useful information in the 252 Soft Set, DNS queries would be sent out on multiple interfaces on 253 relevant PVDs in parallel to maximize chances for connectivity. Some 254 additional discussions of DNS selection consideration of HE-MIF are 255 described in Section 6.3. 257 Once a destination address was resolved, a connection is to be setup. 258 For the given destination address, a PVD-aware node selects a next- 259 hop and source address associated with that PVD in the name 260 resolution process. A PVD agnostic node may receive certain next hop 261 in RA message[RFC4191] , the node selects best source address 262 according to the[RFC6724] rules. When destination and source pairs 263 are identified, it should be treated with higher priority compared to 264 others and choose to initiate the connection in advance. This could 265 avoid thrashing the network, by not making simultaneous connection 266 attempts on multiple interfaces. After making a connection attempt 267 on the preferred pairs and failing to establish a connection within a 268 certain time period (see Section 6.2), a HE-MIF implementation will 269 decide to initiate connection attempt using rest of interfaces in 270 parallel. This fallback consideration may make subsequent connection 271 attempts successful on non-preferable interfaces. 273 The node would cache information regarding the outcome of each 274 connection attempt. Cache entries would be flushed periodically. A 275 system-defined timeout may take place to age the state. Maximum on 276 the order of 10 minutes defined in [RFC6555] is recommended to keep 277 the interface state changes synchronizing with IP family states. 279 If there are no specific Soft Set provided, all selected interfaces 280 should be equally treated. The connections would initiate on several 281 interface simultaneously. The goal here is to provide fast 282 connection for users, by quickly attempting to connect using one of 283 interfaces. Afterwards, the node would do the same caching and 284 flushing process as described above. 286 5. Implementation Framework 288 The simplest way for the implementation is within the application 289 itself. The mechanism described in the document would not require 290 any specific support from the operating system beyond the commonly 291 available APIs that provide transport service. It could also be 292 implemented as high-level API approach, linking to MIF-API 293 [I-D.ietf-mif-api-extension]. A number of enhancements could be 294 added, making the use of the high-level APIs much more productive in 295 building applications. 297 6. Additional Considerations 299 6.1. Usage Scope 301 Connection-oriented transports (e.g., TCP, SCTP) could be directly 302 applied as scoped in [RFC6555]. For connectionless transport 303 protocols (e.g., UDP), a similar mechanism can be used if the 304 application has request/ response semantics (e.g., as done by 305 Interactive Connectivity Establishment (ICE) to select a working IPv6 306 or IPv4 media path[RFC6157])." 308 6.2. Fallback Timeout 310 When the preferred interface was failed, HE-MIF would trigger 311 fallback process to start connection initiation on several candidate 312 interfaces. It should set a reasonable wait time to comfort user 313 experience. Aggressive timeouts may achieve quick interface 314 handover, but at the cost of traffic that may be chargeable on 315 certain networks, e.g. the handover from WiFi to 3/4G would bring a 316 bill to customers. Considering the reasons, it is recommended to 317 prioritize the input from users(e.g. real customers or applications) 318 through user interface. For default-setting on a system, a hard 319 error[RFC1122] in replied ICMP could serve as a trigger for the 320 fallback process. When the ICMP soft error is present or non- 321 response was received, it's recommended that the timeout should be 322 large enough to allow connection retransmission. [RFC1122] states 323 that such timer MUST be at least 3 minutes to provide TCP 324 retransmission. Several minutes delay may not inappropriate for user 325 experiences. A widespread practice[RFC5461] sets 75 seconds to 326 optimize connection process. 328 More optimal timer may be expected. The particular setting will be 329 very specific to implementations and cases. The memo didn't try to 330 provide a concrete value due to following concerns. 332 o RTT(Round-Trip Time) on different interfaces may vary quite a lot. 333 A particular value of timeout may not accurately help to make a 334 decision that this interface doesn't work at all. On the 335 contrary, it may cause a misjudgment on a interface, which is not 336 very fast. In order to compensate the issues, the timeout setting 337 based on past experiences of a particular interface may help to 338 make a fair decision. Whereas, it's going beyond the capability 339 of Happy Eyeballs [RFC6555]. Therefore, it leaves a particular 340 implementation. 342 o In some cases, fast interface may not be treated as "best". For 343 example, a interface could be evaluated in the principle of 344 bandwidth-delay, termed "Bandwidth-Delay-Product ". Happy 345 Eyeballs measures only connection speed. That is, how quickly a 346 TCP connection is established . It does not measure bandwidth. If 347 the fallback has to take various factors into account and make 348 balanced decision, it's better to resort to a specific context and 349 implementation. 351 6.3. DNS Selections 353 In the sort process, HE-MIF prioritizes PVD-ID match or 354 [RFC6731]inputs to select a proper server. It could help to address 355 following two cases. 357 o A DNS answer may be only valid on a specific provisioning domain, 358 but DNS resolver may not be aware of that because DNS reply is not 359 kept with the provisioning from which the answer comes. The 360 situation may become worse if asking internal name with public 361 address response or asking public name with private address 362 answers. 364 o Some FQDNs can be resolvable only by sending queries to the right 365 server (e.g., intranet services). Otherwise, a response with 366 NXDOMAIN is replied. Fast response is treated as optimal only if 367 the record is valid. That may cause messy for data connections, 368 since NXDOMAIN doesn't provide useful information. 370 By doing HE-MIF, it can help to solve the issues of DNS interception 371 with captive portal. The DNS server modified and replied the answer 372 with the IP address of captive portal rather than the intended 373 destination address. In those cases, TCP connection may succeed, but 374 Internet connectivity is not available. It results in lack of 375 service unless user has authenticated. HE-MIF recommended using 376 network connectivity status probes to examine a pre-configured URL 377 for detecting DNS interception on the path (see more in Section 4.2). 378 The node will be able to automatically rely upon other interfaces to 379 select right DNS servers by excluding the unexamined interfaces. 381 6.4. Flow Continuity 383 Interface changing should only happen at the beginning of new session 384 in order to keep flow continuity for ongoing TCP session. Dynamic 385 movement of traffic flows are beyond the scope of this document. 387 7. IANA Considerations 389 This memo includes no request to IANA. 391 8. Security Considerations 393 The security consideration is following the statement in [RFC6555]and 394 [RFC6418]. 396 9. Acknowledgements 398 The authors would like to thank Margaret Wasserman, Hui Deng, Erik 399 Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon 400 Perreault, Zhen Cao, Dmitry Anipko and Ted Lemon for their helpful 401 comments. 403 10. References 405 10.1. Normative References 407 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 408 Communication Layers", STD 3, RFC 1122, 409 DOI 10.17487/RFC1122, October 1989, 410 . 412 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 413 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 414 November 2005, . 416 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 417 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 418 2012, . 420 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 421 "Default Address Selection for Internet Protocol Version 6 422 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 423 . 425 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 426 Recursive DNS Server Selection for Multi-Interfaced 427 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 428 . 430 10.2. Informative References 432 [I-D.ietf-mif-api-extension] 433 Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API 434 consideration", draft-ietf-mif-api-extension-05 (work in 435 progress), February 2014. 437 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 438 DOI 10.17487/RFC5461, February 2009, 439 . 441 [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 442 Transition in the Session Initiation Protocol (SIP)", 443 RFC 6157, DOI 10.17487/RFC6157, April 2011, 444 . 446 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 447 Provisioning Domains Problem Statement", RFC 6418, 448 DOI 10.17487/RFC6418, November 2011, 449 . 451 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 452 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 453 . 455 Authors' Addresses 457 Gang Chen 458 China Mobile 459 29, Jinrong Avenue 460 Xicheng District, 461 Beijing 100033 462 China 464 Email: phdgang@gmail.com, chengang@chinamobile.com 466 Carl Williams 467 Consultant 468 El Camino Real 469 Palo Alto, CA 94306 470 USA 472 Email: carlw@mcsr-labs.org 473 Dan Wing 474 Cisco Systems, Inc. 475 170 West Tasman Drive 476 San Jose, CA 95134 477 USA 479 Email: dwing@cisco.com 481 Andrew Yourtchenko 482 Cisco Systems, Inc. 483 De Kleetlaan, 7 484 Diegem B-1831 485 Belgium 487 Email: ayourtch@cisco.com