idnits 2.17.1 draft-ietf-mif-happy-eyeballs-extension-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2016) is 2824 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) Summary: 1 error (**), 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: February 3, 2017 Consultant 6 D. Wing 7 A. Yourtchenko 8 Cisco Systems, Inc. 9 August 2, 2016 11 Happy Eyeballs Extension for Multiple Interfaces 12 draft-ietf-mif-happy-eyeballs-extension-10 14 Abstract 16 This memo proposes extensions to the Happy Eyeball's algorithm 17 requirements defined in RFC6555 for use with the multiple 18 provisioning domain architecture. The Happy Eyeballs in MIF would 19 make the selection process smoother by using connectivity tests over 20 pre-filtered interfaces according to defined policy. This would 21 choose the best interface with an automatic fallback mechanism. 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 February 3, 2017. 40 Copyright Notice 42 Copyright (c) 2016 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 3.1. WiFi is broken . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Policy Conflict . . . . . . . . . . . . . . . . . . . . . 4 62 4. Happiness Parameters . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Hard Set . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Soft Set . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. HE-MIF Process Requirements . . . . . . . . . . . . . . . . . 5 66 5.1. First Step, Filter . . . . . . . . . . . . . . . . . . . 6 67 5.2. Second Step, Sort . . . . . . . . . . . . . . . . . . . . 6 68 5.2.1. Interface Validation . . . . . . . . . . . . . . . . 6 69 5.2.2. Name Resolution . . . . . . . . . . . . . . . . . . . 7 70 5.2.3. Connection Establishment . . . . . . . . . . . . . . 7 71 6. Implementation Framework . . . . . . . . . . . . . . . . . . 8 72 7. Additional Considerations . . . . . . . . . . . . . . . . . . 8 73 7.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . 8 74 7.2. Fallback Timeout . . . . . . . . . . . . . . . . . . . . 8 75 7.3. DNS Selections . . . . . . . . . . . . . . . . . . . . . 9 76 7.4. Flow Continuity . . . . . . . . . . . . . . . . . . . . . 10 77 7.5. Interworking with Happy Eyeball . . . . . . . . . . . . . 10 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 11.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 The MIF problem statement [RFC6418] describes problems specific for 89 nodes attached to multiple provisioning domains. Specifically, there 90 is a issue description that a node has selected an interface and 91 obtained a valid IP address from the network, but Internet 92 connectivity is not available. This memo intends to address the 93 issue and elaborate more in Section 3.1. 95 [RFC7556] describes the multiple provisioning domain architecture. 96 It refers to using connectivity tests to validate a Provisioning 97 Domain (PvD). Given a number of implicit/explicit PvDs, plus 98 preferences/policy, what is the process to follow to select the best 99 PvD to use for any given connection. In the event that two or more 100 are deemed to be best, how are the Happy Eyeballs (HE) techniques 101 applied to find the best and deal with resilience. This memo also 102 proposes process requirements using Happy Eyeballs (HE) extensions. 104 There are a variety of algorithms that can be envisioned. This 105 document describes additional parameters and processes that need to 106 be considered in addition to the HE algorithm requirements defined in 107 [RFC6555] necessary to support multiple interfaces, so that a node 108 with multiple interfaces can select the best path for a particular 109 connection-oriented flow (e.g., TCP, SCTP). 111 2. Terminology 113 This document makes use of following terms: 115 o Happy Eyeballs (HE): specifies requirements for an algorithm that 116 reduces the user-visible connection delay for dual-stack hosts 117 with a single interface per-protocol. 119 o Happy Eyeballs - Multi-Interface (HE-MIF): Extends the Happy 120 Eyeballs concept to the multiple provisioning domain architecture. 121 It describes additional requirements for algorithms that offer 122 connectivity tests on PVD-aware or non-PVD-aware nodes [RFC7556] 123 to select the best interface for a specific connection request. 125 3. Use Cases 127 The section describes scenarios the HE-MIF targeted to use. 129 3.1. WiFi is broken 131 Assuming a MIF node has both a 3GPP mobile network interface and a 132 WiFi interface, a common practice would be to always prefer the WiFi 133 connection when the node enters an area with WiFi available. In this 134 situation, a node might assume that because a valid IP address has 135 been allocated, the WiFi link provides connectivity to destinations 136 through the Internet. However, this might not be the case for 137 several reasons: 139 o WiFi access-point authentication requirements 141 o WiFi has no global Internet connectivity 143 o Instability at layer 2 144 In order to resolve this problem, the user would need to disable the 145 device's interface preferences, e.g. by disabling the WiFi interface. 146 HE-MIF offers users the possibility of configuring their preferences 147 for the choice of the most suitable network interface to use, such as 148 via setting on their mobile phone. 150 In this case, users may prefer to wait an appropriate time period for 151 connections to be established over a WiFi path. If no connection can 152 be made it will fall back to attempting the connection over a 3GPP 153 mobile network path. 155 3.2. Policy Conflict 157 A node has network access via both WiFi and 3GPP networks. In a 158 mobile network, IPv6-only may be preferable since IPv6 has the 159 potential to be simpler than dual-stack. The WiFi access offers IPv4 160 only. In this scenario, the combination of source address selection 161 [RFC6724] and preferring the WiFi interface may cause a problem. The 162 transition to IPv6 may mean that IPv6 is the preferred protocol, so 163 the 3GPP interface should be chosen even though it could be 164 considered a suboptimal selection e.g. the WiFi interface likely is 165 less expensive. 167 4. Happiness Parameters 169 This section provides input parameter proposal that HE-MIF should 170 catch. Two sets of "Happiness" parameters have been defined. It 171 serves applications and initiates HE-MIF connection tests 172 subsequently. By following the process described below, MIF nodes 173 can select an appropriate interface that best meets the configuration 174 parameters defined by the user. The two sets of "Happiness" 175 parameters are called Hard Set and Soft Set respectively. 177 4.1. Hard Set 179 Hard Set: Contains parameters which should be complied with. It 180 helps to select candidate interfaces through which a particular flow 181 should be directed. These should be seen as constraints on the 182 choice, such as provider policies, support for IPv4 or IPv6, and 183 other parameters which would prevent a particular interface and 184 transport from being used by a particular flow. Parameters in the 185 hard set should be easy to use and understand. When several 186 parameters in the hard set are in conflict, the user's preference 187 should be prioritized. 189 o User's preference: users may express preferences which likely not 190 have a formally technical language , like "No 3/4G while roaming", 191 "Only download applications larger than 20Mb over WiFi", etc. 193 o Operator policy: operators may deliver the customized policies for 194 a particular network environment because of geo-location or 195 service regulation considerations. One example relevant for 3GPP 196 networks is an operator delivering policies from an Access Network 197 Discovery and Selection function (ANDSF) [TS23.402]. 199 4.2. Soft Set 201 Soft Set: Contains factors which impact the selection of the path 202 across which a particular flow should be transmitted among the 203 available interfaces and transports which meet the hard set 204 requirements described above. Examples might include: 206 o PVD-ID (Provisioning Domain Identity): A PVD-aware node may decide 207 to use one preferred PVD or allow the use of multiple PVDs 208 simultaneously for applications. The node behavior should be 209 consistent with MPVD architecture [RFC7556]. 211 o Next hop: [RFC4191] allows the configuration of specific routes to 212 a destination. 214 o DNS selection:The mechanisms described in [RFC6731] could be used 215 to configure nodes with a specific DNS server address for a 216 particular namespace. 218 o Source address selection: The selection process described in 219 [RFC6724] should be considered. 221 o Other factors: Where there is relevant common practice related to 222 interface selection, e.g. Prefer WiFi over a 3GPP interface, if 223 available. Such conventions should also be considered. 225 5. HE-MIF Process Requirements 227 An HE-MIF node may use the two sets of parameters as two steps in the 228 interface selection process. The first step is to use the Hard Set 229 to synthesize policies from different actors (e.g., users or network 230 operators). These hard set parameters will provide a filter which 231 will exclude not qualifying interfaces from any further 232 consideration. 234 The second step is to influence how a node makes a connection when 235 multiple interfaces still remain in the candidate list after first 236 step. This is essentially sorting behavior. In the multiple 237 provisioning domain architecture, a PVD aware node makes connectivity 238 tests as described in Section 5.3 of [RFC7556]. A PVD agnostic node 239 take other parameters apart from PVD-ID in the Soft Set to proceed 240 the sort process. 242 The two steps are described in more details in the following sub- 243 sections. It should be noted that HE-MIF does not prescribe such 244 two-step model. It will be very specific to particular cases and 245 implementations. The two step model mainly describes requirements 246 for how to use the hard/soft set. 248 5.1. First Step, Filter 250 One goal of the filter is to reconcile multiple selection policies 251 from users or operators. Afterwards, merged demands would be mapped 252 to a set of candidate interfaces, which are judged as qualified. 254 Decision on the reconciliation of different policies will depend very 255 much on the deployment scenario. An implementation may not be able 256 to determine priority for each policies without explicit 257 configuration provided by users or administrator. For example, an 258 implementation may by default always prefer the WiFi because of cost 259 saving consideration. Whereas, other users may turn off a device's 260 WiFi interface to guarantee use of a 3GPP network interface to assure 261 higher reliability or security. 263 The decision on mergence of policies may be made by implementations, 264 or by node administrators. However, it's worth to note that a demand 265 from users should be normally considered higher priority than from 266 other actors. 268 The merged policies serve as a filter which is iterated across the 269 list of available interfaces. Qualified interfaces are selected and 270 the proceed to the second step. 272 5.2. Second Step, Sort 274 5.2.1. Interface Validation 276 The Sort process aims to select the best interface and provide 277 fallback capacities. As stated in [RFC7556], a PVD-aware node shall 278 perform connectivity tests and, only after validation of the PVD, 279 consider using it to serve application connections requests. In 280 current implementations, some nodes already implement this, e.g., by 281 trying to reach a dedicated web server (see [RFC6419] ). If anything 282 is abnormal, it assumes there is a proxy on the path. This status 283 detection is recommended to be used in HE-MIF to detect DNS 284 interception or an HTTP proxy that forces a login or a click-through. 285 Unexamined PVDs or interfaces should be accounted as "unconnected". 286 It should not join the sort process. 288 5.2.2. Name Resolution 290 Name resolution is executed on the validated interfaces. Before the 291 requests are initiated, it should check if there is a matching PVD ID 292 for the destination name. A PVD agnostic node may request DNS server 293 selection DHCP option [RFC6731] for interface selection guidance. 294 Those information may weight a particular interface to be preferred 295 to others sending resolving requests. If the node can't find useful 296 information in the Soft Set, DNS queries would be sent out on 297 multiple interfaces in parallel to maximize chances for connectivity. 298 Some additional discussions of DNS selection consideration of HE-MIF 299 are described in Section 7.3. 301 5.2.3. Connection Establishment 303 Once a destination address was resolved, a connection is to be setup. 304 For the given destination address, a PVD-aware node selects a next- 305 hop and source address associated with that PVD in the name 306 resolution process. A PVD agnostic node may receive certain next hop 307 in a RA message [RFC4191], the node selects best source address 308 according to the rules [RFC6724]. 310 When destination and source pairs are identified, it should be 311 treated with higher priority compared to others and choose to 312 initiate the connection in advance. This could avoid thrashing the 313 network, by not making simultaneous connection attempts on multiple 314 interfaces. After making a connection attempt on the preferred pairs 315 and failing to establish a connection within a certain time period 316 (see Section 7.2), a HE-MIF implementation will decide to initiate 317 connection attempt using rest of interfaces in parallel. This 318 fallback consideration will make subsequent connection attempts 319 successful on non-preferable interfaces. 321 The node would cache information regarding the outcome of each 322 connection attempt. Cache entries would be flushed periodically. A 323 system-defined timeout may take place to age the state. Maximum on 324 the order of 10 minutes defined in [RFC6555] is recommended to keep 325 the interface state changes synchronizing with IP family states. 327 If there is no specific Soft Set provided, all selected interfaces 328 should be treated equally. The connections would initiate on several 329 interface simultaneously. The goal here is to provide the most fast 330 connection for users, by quickly attempting to connect using each 331 candidate interface. Afterwards, the node would do the same caching 332 and flushing process as described above. 334 6. Implementation Framework 336 The simplest way to implement the processes described in this 337 document is within the application itself. This would not require 338 any specific support from the operating system beyond the commonly 339 available APIs that provide transport service. It could also be 340 implemented using a high-level API approach, linking to the MIF-API 341 [I-D.ietf-mif-api-extension]. 343 7. Additional Considerations 345 7.1. Usage Scope 347 Connection-oriented transports (e.g., TCP, SCTP) are directly applied 348 as scoped in [RFC6555]. For connectionless transport protocols 349 (e.g., UDP), a similar mechanism can be used if the application has 350 request/response semantics. Further investigations are out of the 351 document scope. 353 7.2. Fallback Timeout 355 When the preferred interface was failed, HE-MIF would trigger a 356 fallback process to start connection initiation on several candidate 357 interfaces. It should set a reasonable wait time to comfort user 358 experience. 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 3GPP networks brings 361 a charge to customers. Considering the reasons, it is recommended to 362 prioritize the input from users (e.g., real customers or 363 applications) through user interface. For default-setting on a 364 system, a hard error [RFC1122] in replied ICMP could serve as a 365 trigger for the fallback process. When the ICMP soft error is 366 present or non-response was received, it's recommended that the 367 timeout should be large enough to allow connection retransmission. 368 [RFC1122] states that such timer must be at least 3 minutes to 369 provide TCP retransmission. However, several minutes delay may not 370 inappropriate for user experiences. A widespread practice [RFC5461] 371 sets 75 seconds to 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 because of following concerns. 377 o RTT (Round-Trip Time) on different interfaces may vary quite a 378 lot. A particular value of timeout may not accurately help to 379 make a 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 leaves a particular 385 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 7.3. DNS Selections 398 During the Sort process, HE-MIF prioritizes PVD-ID match or [RFC6731] 399 inputs to select a proper server. It could help to address following 400 two cases. 402 o A DNS answer may be only valid for a specific provisioning domain, 403 but the DNS resolver may not be aware of that because the DNS 404 reply is not kept with the provisioning from which the answer 405 comes. The situation may become worse if asking internal name 406 with public address response or asking public name with private 407 address 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. Fast response is treated as optimal only if 412 the record is valid. That may cause messy for data connections, 413 since NXDOMAIN doesn't provide useful information. 415 HE-MIF can help to solve the issues of DNS interception with captive 416 portal. The DNS server modified and replied the answer with the IP 417 address of captive portal rather than the intended destination 418 address. In those cases, TCP connection may succeed, but Internet 419 connectivity is not available. It results in lack of service unless 420 user has authenticated. HE-MIF recommended using network 421 connectivity status probes to examine a pre-configured URL for 422 detecting DNS interception on the path (see more in Section 5.2). 423 The node will be able to automatically rely upon other interfaces to 424 select right DNS servers by excluding the unexamined interfaces. 426 7.4. Flow Continuity 428 [I-D.deng-mif-api-session-continuity-guide] describes session 429 continuity guidance for application developers. The flow continuity 430 topic is beyond this document scope. 432 7.5. Interworking with Happy Eyeball 434 HE-MIF process could cooperate with HE [RFC6555]. HE is executed on 435 an interface which is selected to make connection establishment (see 436 Section 5.2.3). For example, a node following PvD policy to pick a 437 interface and make both IPv4/IPv6 connection attempts in consistent 438 with HE requirements. The interface state management in HE-MIF is 439 designed to synchronize with IP family states. It could facilitate 440 the HE executions. 442 8. IANA Considerations 444 This memo does not include any IANA requests. 446 9. Security Considerations 448 The security consideration is following the statement in [RFC6555] 449 and [RFC6418]. 451 10. Acknowledgements 453 The authors would like to thank Margaret Wasserman, Hui Deng, Erik 454 Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon 455 Perreault, Zhen Cao, Dmitry Anipko, Ted Lemon, Daniel Migault, Russ 456 White and Bing Liu for their helpful comments. 458 Many thanks to Ralph Droms, Ian Farrer and Jouni Korhonen for their 459 detailed reviews. 461 11. References 463 11.1. Normative References 465 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 466 Communication Layers", STD 3, RFC 1122, 467 DOI 10.17487/RFC1122, October 1989, 468 . 470 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 471 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 472 November 2005, . 474 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 475 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 476 2012, . 478 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 479 "Default Address Selection for Internet Protocol Version 6 480 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 481 . 483 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 484 Recursive DNS Server Selection for Multi-Interfaced 485 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 486 . 488 [TS23.402] 489 3rd Generation Partnership Project, 3GPP., "Architecture 490 enhancements for non-3GPP accesses v8.8.0", December 2009. 492 11.2. Informative References 494 [I-D.deng-mif-api-session-continuity-guide] 495 Deng, H., Krishnan, S., Lemon, T., and M. Wasserman, 496 "Guide for application developers on session continuity by 497 using MIF API", draft-deng-mif-api-session-continuity- 498 guide-04 (work in progress), July 2014. 500 [I-D.ietf-mif-api-extension] 501 Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API 502 consideration", draft-ietf-mif-api-extension-05 (work in 503 progress), February 2014. 505 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 506 DOI 10.17487/RFC5461, February 2009, 507 . 509 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 510 Provisioning Domains Problem Statement", RFC 6418, 511 DOI 10.17487/RFC6418, November 2011, 512 . 514 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 515 Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419, 516 November 2011, . 518 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 519 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 520 . 522 Authors' Addresses 524 Gang Chen 525 China Mobile 526 29, Jinrong Avenue 527 Xicheng District, 528 Beijing 100033 529 China 531 Email: phdgang@gmail.com, chengang@chinamobile.com 533 Carl Williams 534 Consultant 535 El Camino Real 536 Palo Alto, CA 94306 537 USA 539 Email: carlw@mcsr-labs.org 541 Dan Wing 542 Cisco Systems, Inc. 543 170 West Tasman Drive 544 San Jose, CA 95134 545 USA 547 Email: dwing@cisco.com 549 Andrew Yourtchenko 550 Cisco Systems, Inc. 551 De Kleetlaan, 7 552 Diegem B-1831 553 Belgium 555 Email: ayourtch@cisco.com