idnits 2.17.1 draft-ietf-mif-happy-eyeballs-extension-08.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 335: '... [RFC1122] states that such timer MUST be at least 3 minutes to...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 20, 2015) is 3022 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: June 22, 2016 Consultant 6 D. Wing 7 A. Yourtchenko 8 Cisco Systems, Inc. 9 December 20, 2015 11 Happy Eyeballs Extension for Multiple Interfaces 12 draft-ietf-mif-happy-eyeballs-extension-08 14 Abstract 16 This memo proposes extensions to the Happy Eyeball(HE) defined in 17 RFC6555 and fit into a multiple provisioning domain architecture. 18 Happy Eyeballs in MIF would make the selection process smoother by 19 using connectivity tests over pre-filtered interfaces according to 20 defined policy. This would choose the most fast interface with an 21 automatic fallback mechnism. 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 June 22, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Happiness Parameters . . . . . . . . . . . . . . . . . . . . 4 61 5. HE-MIF behavior . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. First Step, Filter . . . . . . . . . . . . . . . . . . . 5 63 5.2. Second Step, Sort . . . . . . . . . . . . . . . . . . . . 6 64 6. Implementation Framework . . . . . . . . . . . . . . . . . . 7 65 7. Additional Considerations . . . . . . . . . . . . . . . . . . 7 66 7.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.2. Fallback Timeout . . . . . . . . . . . . . . . . . . . . 7 68 7.3. DNS Selections . . . . . . . . . . . . . . . . . . . . . 8 69 7.4. Flow Continuity . . . . . . . . . . . . . . . . . . . . . 9 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 11.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 In a multiple interface context, the problems raised by hosts with 81 multiple interfaces have been discussed in the MIF problem statement 82 [RFC6418], which describes the various issues when using a wrong 83 domain selection on a MIF node. Happy Eyeballs (HE) [RFC6555] 84 describes how a dual-stack client can determine the most fast path to 85 a dual-stack server by employing a stateful algorithm to quickly 86 discover if the IPv4 or IPv6 path is faster. while this is a good 87 method to achieve smart path selection, it assumes a single-homed 88 node targeted. Interaction with multiple interfaces was deferred for 89 further study. 91 [RFC7556] has proposed a multiple provisioning domain architecture. 92 This memo proposes extensions to the Happy Eyeball(HE) defined in 93 [RFC6555] to support multiple interfaces, such that a node with 94 multiple interfaces can choose the most fast path for a particular 95 connection-oriented flow (e.g., TCP, SCTP). 97 2. Terminology 99 This document makes use of following terms: 101 o Happy Eyeballs (HE): it specifies requirements for algorithms that 102 reduce user-visible delay of dual-stack hosts within a single 103 home. 105 o HE-MIF: it adopts Happy Eyeballs concept [RFC6555] to the multiple 106 provisioning domain architecture. It describes requirements for 107 algorithms that offer connectivity tests on PVD-aware or non-PVD- 108 aware nodes [RFC7556] to select the most fast interface. 110 3. Use Cases 112 The section describes use cases in existing networks. 114 Use Case: WiFi is broken 116 Assuming a MIF node has both 3GPP mobile network interface and WiFi 117 interface, a common practice would always prefer WiFi connection when 118 the node enters a WiFi area. In this situation, a node might assume 119 the WiFi link can reach destinations on the global Internet, because 120 a valid IP address has been assigned on the interface. However, this 121 might not be the case for several reasons, such as authentication 122 requirements, instability at layer 2, or even, perhaps, the WiFi 123 being connected to a local network with no global Internet 124 reachability. In order to figure out the problems, a user has to 125 turn off the WiFi manually. With HE-MIF, users can indicate their 126 desire with some setting on the phone. For instance, they may prefer 127 to wait an appropriate time slot but not forever. After the timer is 128 expired, users may finally give up the WiFi path and try to establish 129 connection over a 3GPP mobile network path. Users may not want a 130 very short timer, because the mobile network path for most people is 131 more expensive than a WiFi path. An appropriate timer is desired to 132 balance user experience and expenditure. 134 Use Case: Policy Conflict 136 A node has both WiFi and 3GPP network access simultaneously. In a 137 mobile network, IPv6-only may be preferable since IPv6 has the 138 potential to be simpler than dual-stack. WiFi access still remains 139 on IPv4. The problem is caused by source address selection principle 140 [RFC6724] and wifi preference. The transition to IPv6 is likely to 141 encourage and prefer IPv6 . If a 3GPP network path has IPv6 on it and 142 a WiFi does not, the 3GPP interface might be chosen while it maybe a 143 suboptimal selection since the wifi interface likely is less 144 expensive. With HE-MIF, user's interests could be well understood 145 and considered before interface selection. Different preconditions 146 can impact subsequent behaviors. Users concern about high- 147 reliability or high-speed or less-cost would make different choicies. 148 A flexible mechanism is provided to make smart decision. 150 4. Happiness Parameters 152 This section provides a design proposal for HE-MIF. Two sets of 153 "Happiness" parameters have been defined. It serves applications and 154 initiates HE-MIF connections tests subsequently. Going through the 155 process, MIF nodes could pick an appropriate interface which would 156 correspond to user demands. The two sets of "Happiness" parameters 157 are called Hard Set and Soft Set respectively. 159 o Hard Set: Contains parameters which must be complied with. It 160 helps to select candidate interfaces through which a particular 161 flow should be directed. These should be seen as constraints on 162 the choice, such as provider policies, support for IPv4 or IPv6, 163 and other parameters which would prevent a particular interface 164 and transport from being used by a particular flow. Parameters in 165 the hard set should be easy to use and understand. When several 166 parameters in the hard set are in conflict, the user's preference 167 should be prioritized. 169 * User's preference: users may express preferences which likely 170 not have a formally technical language , like "No 3G while 171 roaming", "Only use free WiFi", etc. 173 * Operator policy: operators may deliver the customized policies 174 in a particular network environment because of geo-location or 175 services regulation considerations. One example in 3GPP 176 network is that operator could deliver policies from access 177 network discovery and selection function (ANDSF). 179 o Soft Set: Contains factors which impact the selection of the path 180 across which a particular flow should be transmitted among the 181 available interfaces and transports which meet the hard set 182 requirements described above. Examples might include: 184 * PVD-ID (Provisioning Domain Identity): PVD-aware node may 185 decide to use one preferred PVD or allow use multiple PVDs 186 simultaneously for applications. The node behavior should be 187 consistent with MPVD architecture [RFC7556]. 189 * Next hop: [RFC4191] allows configuration of specific routes to 190 a destination. 192 * DNS selection: [RFC6731] could configure nodes with information 193 to indicate a DNS server address for a particular namespace. 195 * Source address selection: the information provided by [RFC6724] 196 should be considered. 198 * Other factors: There is a common practice may impact interface 199 selection, e.g. WiFi is preferable. Such conventional 200 experiences should also be considered. 202 5. HE-MIF behavior 204 Corresponding to the two sets of parameters, a HE-MIF node may take a 205 two-steps approach. One is to do "Hard" decision to synthesize 206 policies from different actors (e.g., users and network operator). 207 In a nutshell, that is a filter which will exclude the interfaces 208 from any further consideration. The second is to adjust how a node 209 make a connection on multiple interfaces after the filter. It's 210 sorting behavior. In the multiple provisioning domain architecture, 211 a PVD aware node takes connectivity tests as described in Section 5.3 212 of [RFC7556]. A PVD agnostic node take other parameters in the Soft 213 Set to proceed the sort process. 215 Those two steps are described as following sub-sections. It should 216 be noted that HE-MIF doesn't prescribe such two-step model. It will 217 be very specific to particular cases and implementations. For 218 example, if only one interface is left after the first step, the 219 process is likely ceased. 221 5.1. First Step, Filter 223 One goal of the filter is to reconcile multiple selection policies 224 from users or operators. Afterwards, merged demands would be mapped 225 to a set of candidate interfaces, which is judged as qualified. 227 Decision on reconciliation of different policies will depend very 228 much on the deployment scenario. An implementation may not be able 229 to determine priority for each policies without explicit 230 configuration provided by users or administrator. For example, an 231 implementation may by default always prefer the WiFi because of cost 232 saving consideration. Whereas, users may dedicatedly prefer a 3GPP 233 network interface to seek high-reliability or security benefits even 234 to manually turn off WiFi interface. The decision on mergence of 235 policies may be made by implementations, by node administrators, even 236 by other standards investigating customer behavior. However, it's 237 worth to note that a demand from users should be normally considered 238 higher priority than from other actors. 240 The merged policies would serve as a filter principle doing iterate 241 across the list of all known interfaces. Qualified interface would 242 be selected to Sort processing at the next step. 244 5.2. Second Step, Sort 246 A Sort process guarantees a fast interface selection with fallback 247 capacities. As stated in [RFC7556], a PVD-aware node shall perform 248 connectivity test and, only after validation of the PVD, consider 249 using it to serve application connections requests. In current 250 implementations, some nodes already implement this, e.g., by trying 251 to reach a dedicated web server (see [RFC6419] ). If anything is 252 abnormal, it assumes there is a proxy on the path. This status 253 detection is recommended to be used in HE-MIF to detect DNS 254 interception or HTTP proxy that forces a login or a click-through. 255 Unexamined PVDs or interfaces should be accounted as "unconnected". 256 It should not join the sort process. 258 Afterwards, two phases normally are involved in a Sort process, i.e., 259 name resolving and connection establishment. The Soft set parameters 260 defined in Section 4 should considered at this stage. 262 When a node initiates name resolution requests, it should check if 263 there is a matched PVD ID for the destination name. A PVD agnostic 264 node may request DNS server selection DHCP option [RFC6731] for 265 interface selection guidance. Those information may weight a 266 particular interface to be preferred to others sending resolving 267 requests. If the node can't find useful information in the Soft Set, 268 DNS queries would be sent out on multiple interfaces in parallel to 269 maximize chances for connectivity. Some additional discussions of 270 DNS selection consideration of HE-MIF are described in Section 7.3. 272 Once a destination address was resolved, a connection is to be setup. 273 For the given destination address, a PVD-aware node selects a next- 274 hop and source address associated with that PVD in the name 275 resolution process. A PVD agnostic node may receive certain next hop 276 in a RA message [RFC4191], the node selects best source address 277 according to the rules [RFC6724]. When destination and source pairs 278 are identified, it should be treated with higher priority compared to 279 others and choose to initiate the connection in advance. This could 280 avoid thrashing the network, by not making simultaneous connection 281 attempts on multiple interfaces. After making a connection attempt 282 on the preferred pairs and failing to establish a connection within a 283 certain time period (see Section 7.2), a HE-MIF implementation will 284 decide to initiate connection attempt using rest of interfaces in 285 parallel. This fallback consideration will make subsequent 286 connection attempts successful on non-preferable interfaces. 288 The node would cache information regarding the outcome of each 289 connection attempt. Cache entries would be flushed periodically. A 290 system-defined timeout may take place to age the state. Maximum on 291 the order of 10 minutes defined in [RFC6555] is recommended to keep 292 the interface state changes synchronizing with IP family states. 294 If there are no specific Soft Set provided, all selected interfaces 295 should be equally treated. The connections would initiate on several 296 interface simultaneously. The goal here is to provide the most fast 297 connection for users, by quickly attempting to connect using each 298 candidate interface. Afterwards, the node would do the same caching 299 and flushing process as described above. 301 6. Implementation Framework 303 The simplest way for the implementation is within the application 304 itself. The mechanism described in the document would not require 305 any specific support from the operating system beyond the commonly 306 available APIs that provide transport service. It could also be 307 implemented as high-level API approach, linking to MIF-API 308 [I-D.ietf-mif-api-extension]. 310 7. Additional Considerations 312 7.1. Usage Scope 314 Connection-oriented transports (e.g., TCP, SCTP) are directly applied 315 as scoped in [RFC6555]. For connectionless transport protocols 316 (e.g., UDP), a similar mechanism can be used if the application has 317 request/response semantics. Further investigrations are out of the 318 document scope. 320 7.2. Fallback Timeout 322 When the preferred interface was failed, HE-MIF would trigger a 323 fallback process to start connection initiation on several candidate 324 interfaces. It should set a reasonable wait time to comfort user 325 experience. Aggressive timeouts may achieve quick interface 326 handover, but at the cost of traffic that may be chargeable on 327 certain networks, e.g. the handover from WiFi to 3GPP networks brings 328 a charge to customers. Considering the reasons, it is recommended to 329 prioritize the input from users (e.g., real customers or 330 applications) through user interface. For default-setting on a 331 system, a hard error [RFC1122] in replied ICMP could serve as a 332 trigger for the fallback process. When the ICMP soft error is 333 present or non-response was received, it's recommended that the 334 timeout should be large enough to allow connection retransmission. 335 [RFC1122] states that such timer MUST be at least 3 minutes to 336 provide TCP retransmission. However, several minutes delay may not 337 inappropriate for user experiences. A widespread practice [RFC5461] 338 sets 75 seconds to optimize connection process. 340 More optimal timer may be expected. The particular setting will be 341 very specific to implementations and cases. The memo didn't try to 342 provide a concrete value because of following concerns. 344 o RTT (Round-Trip Time) on different interfaces may vary quite a 345 lot. A particular value of timeout may not accurately help to 346 make a decision that this interface doesn't work at all. On the 347 contrary, it may cause a misjudgment on a interface, which is not 348 very fast. In order to compensate the issues, the timeout setting 349 based on past experiences of a particular interface may help to 350 make a fair decision. Whereas, it's going beyond the capability 351 of Happy Eyeballs [RFC6555]. Therefore, it leaves a particular 352 implementation. 354 o In some cases, fast interface may not be treated as "best". For 355 example, a interface could be evaluated in the principle of 356 bandwidth-delay, termed "Bandwidth-Delay-Product ". Happy 357 Eyeballs measures only connection speed. That is, how quickly a 358 TCP connection is established . It does not measure bandwidth. If 359 the fallback has to take various factors into account and make 360 balanced decision, it's better to resort to a specific context and 361 implementation. 363 7.3. DNS Selections 365 In the Sort process, HE-MIF prioritizes PVD-ID match or 366 [RFC6731]inputs to select a proper server. It could help to address 367 following two cases. 369 o A DNS answer may be only valid on a specific provisioning domain, 370 but DNS resolver may not be aware of that because DNS reply is not 371 kept with the provisioning from which the answer comes. The 372 situation may become worse if asking internal name with public 373 address response or asking public name with private address 374 answers. 376 o Some FQDNs can be resolvable only by sending queries to the right 377 server (e.g., intranet services). Otherwise, a response with 378 NXDOMAIN is replied. Fast response is treated as optimal only if 379 the record is valid. That may cause messy for data connections, 380 since NXDOMAIN doesn't provide useful information. 382 By doing HE-MIF, it can help to solve the issues of DNS interception 383 with captive portal. The DNS server modified and replied the answer 384 with the IP address of captive portal rather than the intended 385 destination address. In those cases, TCP connection may succeed, but 386 Internet connectivity is not available. It results in lack of 387 service unless user has authenticated. HE-MIF recommended using 388 network connectivity status probes to examine a pre-configured URL 389 for detecting DNS interception on the path (see more in Section 5.2). 390 The node will be able to automatically rely upon other interfaces to 391 select right DNS servers by excluding the unexamined interfaces. 393 7.4. Flow Continuity 395 [I-D.deng-mif-api-session-continuity-guide] describes session 396 continuity guidance for application developers. The flow continuity 397 topic is beyond this document scope. 399 8. IANA Considerations 401 This memo includes no request to IANA. 403 9. Security Considerations 405 The security consideration is following the statement in [RFC6555]and 406 [RFC6418]. 408 10. Acknowledgements 410 The authors would like to thank Margaret Wasserman, Hui Deng, Erik 411 Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon 412 Perreault, Zhen Cao, Dmitry Anipko, Ted Lemon, Daniel Migault, Russ 413 White and Bing Liu for their helpful comments. 415 11. References 417 11.1. Normative References 419 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 420 Communication Layers", STD 3, RFC 1122, 421 DOI 10.17487/RFC1122, October 1989, 422 . 424 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 425 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 426 November 2005, . 428 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 429 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 430 2012, . 432 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 433 "Default Address Selection for Internet Protocol Version 6 434 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 435 . 437 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 438 Recursive DNS Server Selection for Multi-Interfaced 439 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 440 . 442 11.2. Informative References 444 [I-D.deng-mif-api-session-continuity-guide] 445 Deng, H., Krishnan, S., Lemon, T., and M. Wasserman, 446 "Guide for application developers on session continuity by 447 using MIF API", draft-deng-mif-api-session-continuity- 448 guide-04 (work in progress), July 2014. 450 [I-D.ietf-mif-api-extension] 451 Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API 452 consideration", draft-ietf-mif-api-extension-05 (work in 453 progress), February 2014. 455 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 456 DOI 10.17487/RFC5461, February 2009, 457 . 459 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 460 Provisioning Domains Problem Statement", RFC 6418, 461 DOI 10.17487/RFC6418, November 2011, 462 . 464 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 465 Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419, 466 November 2011, . 468 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 469 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 470 . 472 Authors' Addresses 473 Gang Chen 474 China Mobile 475 29, Jinrong Avenue 476 Xicheng District, 477 Beijing 100033 478 China 480 Email: phdgang@gmail.com, chengang@chinamobile.com 482 Carl Williams 483 Consultant 484 El Camino Real 485 Palo Alto, CA 94306 486 USA 488 Email: carlw@mcsr-labs.org 490 Dan Wing 491 Cisco Systems, Inc. 492 170 West Tasman Drive 493 San Jose, CA 95134 494 USA 496 Email: dwing@cisco.com 498 Andrew Yourtchenko 499 Cisco Systems, Inc. 500 De Kleetlaan, 7 501 Diegem B-1831 502 Belgium 504 Email: ayourtch@cisco.com