Internet Engineering Task Force G. Chen Internet-Draft China Mobile Intended status: Informational C. Williams Expires: December 25, 2014 Consultant D. Wing A. Yourtchenko Cisco Systems, Inc. June 23, 2014 Happy Eyeballs Extension for Multiple Interfaces draft-ietf-mif-happy-eyeballs-extension-05 Abstract Currently the interface selection in multi-interface environment is exclusive - only one interface can be used at the time, frequently needing manual intervention. Happy Eyeballs in MIF would make the selection process smoother by using the connectivity checks over a pre-filtered interfaces according to defined policy. This would choose the fastest interface with an automatic fallback. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 25, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Chen, et al. Expires December 25, 2014 [Page 1] Internet-Draft happy-eyeballs-mif June 2014 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Happiness Parameters . . . . . . . . . . . . . . . . . . . . 5 4. HE Behavior in MIF . . . . . . . . . . . . . . . . . . . . . 6 4.1. First Step, Filter . . . . . . . . . . . . . . . . . . . 6 4.2. Second Step, Sort . . . . . . . . . . . . . . . . . . . . 7 5. Implementation Framework . . . . . . . . . . . . . . . . . . 8 6. Additional Considerations . . . . . . . . . . . . . . . . . . 8 6.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Fallback Timeout . . . . . . . . . . . . . . . . . . . . 8 6.3. DNS Selections . . . . . . . . . . . . . . . . . . . . . 9 6.4. Flow Continuity . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction In multiple interface context, the problems raised by hosts with multiple interfaces have been discussed. The MIF problem statement[RFC6418] described the various issues when using a wrong domain selection on a MIF node. Happy Eyeballs (HE) [RFC6555] described how a dual-stack client can determine the functioning path to a dual-stack server. It's using stateful algorithm to help applications quickly determine if IPv6 or IPv4 is the most fast path to connect a server. That is a good method to achieve smart path selection. However, the assumption is a single-homed context. The interaction with multiple interfaces is deferred for further study. [I-D.ietf-mif-mpvd-arch] has proposed a multiple provisioning domain architecture. This memo has been proposed to extend happy eyeballs algorithm to fit into the multiple interfaces architecture. Several additional considerations have been elaborated to analyze the user demands and initiate HE-MIF connections. It allows a node with multiple interfaces picking a fast flow path. Chen, et al. Expires December 25, 2014 [Page 2] Internet-Draft happy-eyeballs-mif June 2014 2. Use Cases The section enumerates several concrete use cases in existing networks. Case 1: WiFi is broken o [Scenario] A MIF node has both 3/4G and WiFi interface. When the node enters a WiFi area, a common practice would always prefer WiFi because it' cheap and fast-speed normally. o [Problem] User assumes the WiFi is working, because the node already got IP address from WiFi. However, he can't run applications due to Internet connectivity being unavailable. This may be an authentication required coming into play, or unstable Layer 2 conditions. In order to figure out the problems, users have to turn off the WiFi manually. o [Workaround] Users can indicate their desire with some setting on the phone. For instance, they may prefer to wait a little bit of time but not forever. After the timer is expired, users would finally give up the WiFi path and try to establish connection over 3G path. Users may won't want the wait time too short, because the 3G path for most people is more expensive than WiFi path. Case 2: VPN (Virtual Private Network) scenario o [Scenario] In some cases, a node has multiple interface because of VPN. Users would only have interests to connect a corporate network inside VPN. While, connecting to Internet would work outside the VPN. o [Problem] That is normally a implementation consideration that unmanaged interface may be considered less trustworthy than managed. It results in trusted interfaces having the highest priority. This setting may steer all traffic to VPN interface. When this is a traffic heading to a corporate site, everything is fine. But sometimes, the connections out to Internet sites may suffer from long-distance path delays. o [Workaround] It's desirable if routing could be bound to each interface. However, a node following weak host model[RFC1122] takes routing tables as node-scoped. Some sophisticated VPN clients may enable split tunneling to access a public network (e.g. the Internet) and a local LAN simultaneously. VPN may adopt different security policies to applications, for example disable split tunneling to enforce security tunnel only to a particular application. It may be useful to facilitate the implementation by Chen, et al. Expires December 25, 2014 [Page 3] Internet-Draft happy-eyeballs-mif June 2014 performing parallel IP connectivity checks before selecting an interface. Case 3: 3G/LTE tethering scenario o [Scenario] Many mobile phones are equipped with software to offer tethered Internet access. It shares their Internet connection with another Internet-capable mobile phone or other devices over Wi-Fi. o [Problem] The tethering WiFi link is not free , i.e., it might be 3/4G backhaul. The policy of "always WiFi" leads to all traffic being sent over the tethering WiFi. Usually, such tethering WiFi link puts sharing limitation to access nodes. It could cause contention on both that WiFi link and the backhaul 3G link, while it be higher cost than going on the 3/4G that is built in the handset. o [Workaround] To solve that, it is necessary for the node to be aware of not only the link layer information, but also services information, like billable or free. That could help to facilitate the execution of the algorithm. Same concern has been documented in Section 4.4 of [RFC6418]) Case 4: Policy Conflict o [Scenario] A node has WiFi and 3/4G access simultaneously. In mobile network, IPv6-only may be preferable since IPv6 has the potential to be simpler than dual-stack. WiFi access still remains on IPv4. o [Problem] The problem is caused by policy confliction. The transition to IPv6 is likely to encourage IPv6 and prefer IPv6[RFC6724]. If the 3/4G path has IPv6 on it and the WiFi does not, a suboptimal interface might be chosen from the cost saving perspective. o [Workaround] Users interests should be well understood and considered before interface selection. The different preconditions may impact subsequent behaviors. Users concern about high-reliability or high-speed or less-cost should make different choice. A flexible mechanism should be provided allow to make smart decision. Chen, et al. Expires December 25, 2014 [Page 4] Internet-Draft happy-eyeballs-mif June 2014 3. Happiness Parameters This section provides the design proposal for HE-MIF. Two sets of "Happiness" parameters have been defined. It serves upper applications and initiates HE-MIF connections to below level API subsequently. Going through the process, MIF nodes could pick an appropriate interface which would correspond to user demands. The two sets of "Happiness" parameters are called Hard set and Soft set respectively. o Hard Set: It contains parameters which have mandatory indications that interface behavior should comply with. This might provide an interface for applications constraints or delivering operator's policies. Basically, parameters in Hard set should be easy-to-use and easy-to-understand. The users would directly use those. When several hard parameters were conflicted, user's preference should be prioritized. * User's preference: users would express preferences which may not have a formally technical language , like "No 3G while roaming", "Only use free WiFi", etc. * Operator policy: operators would deliver the customized policies in particular network environments due to geo-location or services regulation considerations. One example in 3GPP network is that operator could deliver policies from access network discovery and selection function (ANDSF). o Soft Set: It contains factors involving in the selection of the fastest path. The following is considered as for the justification. * PVD-ID (Provisioning Domain Identity): PVD-aware node may decide to use one preferred PVD or allow use mulitple PVDs simultanenously for applications. The node behavior should be consistent with MPVD architecture. * Next hop: [RFC4191] allows configuration of specific routes to a destination. * DNS selection: [RFC6731] could configure nodes with information to indicate DNS server address for a particular namespace. * Source address selection: the information provided by [RFC6724] would be considered. Chen, et al. Expires December 25, 2014 [Page 5] Internet-Draft happy-eyeballs-mif June 2014 * Other factors: There is a common practice may impact interface selection, e.g. WiFi is preferable. Such conventional experiences should also be considered. 4. HE Behavior in MIF Corresponding to the two sets of parameters, a HE-MIF node may take a two-steps approach. One is to do "Hard" decision to synthesize policies from different actors (e.g., users and network operator). In a nutshell, that is a filter which will exclude the interfaces from any further consideration. The second is to adjust how we make a connection on multiple interfaces after the filter. It's sorting behavior. In the multiple provisioning domain architecture, a PVD aware node takes connectivity tests as described in Section 5.3 of [I-D.ietf-mif-mpvd-arch]. A PVD agnostic node take other parameters in the Soft Set to proceed the sort process. Those two steps are described as following sub-sections. It should be noted that HE-MIF doesn't prescribe such two-step model. It will be very specific to particular cases and implementations. For example, if one interface on a particular PVD is left after the first step, the process would be ceased. 4.1. First Step, Filter One goal of filter is to reconcile multiple selection policies from users or operators. Afterwards, the merged demands would be mapped to a set of candidate interfaces, which is judged as qualified. Decision on reconciliation of different policies will depend very much on the deployment scenario. An implementation may not be able to determine priority for each policies without explicit configuration provided by users or administrator. For example, an implementation may by default always prefer the WiFi due to cost saving consideration. Whereas, users may dedicatedly prefer 3/4G interface to seek high-reliability or security benefits even to manually turn off WiFi interface. The decision on mergence of policies may be made by implementations, by node administrators, even by other standards investigating customer behavior. However, it's worth to note that a demand from users should be normally considered higher priority than from other actors. The merged policies would serve as a filter principle doing iterate across the list of all known interfaces. Qualified interface would be selected to sort processing at next step. Chen, et al. Expires December 25, 2014 [Page 6] Internet-Draft happy-eyeballs-mif June 2014 4.2. Second Step, Sort Sort process guarantees fast interface selection with fallback capacities. As stated in [I-D.ietf-mif-mpvd-arch], a PVD-aware node shall perform connectivity test and, only after validation of the PVD, consider using it to serve application connections requests. A common practise is to probe a pre-configured URL to check network connectivity status as soon as a node access a network at bootstrap or changes to different networks, e.g. Windows Vista, Windows 7, Windows Server 2008 and iOS. If anything is abnormal, it assumes there is a proxy on the path. This status detection is recommended to be used in HE-MIF to detect DNS interception or HTTP proxy that forces a login or a click-through. Unexamined PVDs or interfaces should be accounted as "unconnected". It should not join the sort process. Afterwards, two phases normally are involved in a sort process, i.e. name resolving and connection establishment. Parameters in a soft set should considered at this stage. When a node initiates name resolution requests, it should check if there is a matched PVD ID for the destination name. A PVD agnostic node may request DNS server selection DHCP option[RFC6731] for interface selection guidance. Those information may weight a particular interface to be preferred one prior to others sending resolving requests. If the node can't find useful information in the Soft Set, DNS queries would be sent out on multiple interfaces on relevant PVDs in parallel to maximize chances for connectivity. Some additional discussions of DNS selection consideration of HE-MIF are described in Section 6.3. Once a destination address was resolved, a connection is to be setup. For the given destination address, a PVD-aware node selects a next- hop and source address associated with that PVD in the name resolution process. A PVD agnostic node may receive certain next hop in RA message[RFC4191] , the node selects best source address according to the[RFC6724] rules. When destination and source pairs are identified, it should be treated with higher priority compared to others and choose to initiate the connection in advance. This could avoid thrashing the network, by not making simultaneous connection attempts on multiple interfaces. After making a connection attempt on the preferred pairs and failing to establish a connection within a certain time period (see Section 6.2), a HE-MIF implementation will decide to initiate connection attempt using rest of interfaces in parallel. This fallback consideration may make subsequent connection attempts successful on non-preferable interfaces. Chen, et al. Expires December 25, 2014 [Page 7] Internet-Draft happy-eyeballs-mif June 2014 The node would cache information regarding the outcome of each connection attempt. Cache entries would be flushed periodically. A system-defined timeout may take place to age the state. Maximum on the order of 10 minutes defined in [RFC6555] is recommended to keep the interface state changes synchronizing with IP family states. If there are no specific Soft Set provided, all selected interfaces should be equally treated. The connections would initiate on several interface simultaneously. The goal here is to provide fast connection for users, by quickly attempting to connect using one of interfaces. Afterwards, the node would do the same caching and flushing process as described above. 5. Implementation Framework The simplest way for the implementation is within the application itself. The mechanism described in the document would not require any specific support from the operating system beyond the commonly available APIs that provide transport service. It could also be implemented as high-level API approach, linking to MIF-API [I-D.ietf-mif-api-extension]. A number of enhancements could be added, making the use of the high-level APIs much more productive in building applications. 6. Additional Considerations 6.1. Usage Scope Connection-oriented transports (e.g., TCP, SCTP) could be directly applied as scoped in [RFC6555]. For connectionless transport protocols (e.g., UDP), a similar mechanism can be used if the application has request/ response semantics (e.g., as done by Interactive Connectivity Establishment (ICE) to select a working IPv6 or IPv4 media path[RFC6157])." 6.2. Fallback Timeout When the preferred interface was failed, HE-MIF would trigger fallback process to start connection initiation on several candidate interfaces. It should set a reasonable wait time to comfort user experience. Aggressive timeouts may achieve quick interface handover, but at the cost of traffic that may be chargeable on certain networks, e.g. the handover from WiFi to 3/4G would bring a bill to customers. Considering the reasons, it is recommended to prioritize the input from users(e.g. real customers or applications) through user interface. For default-setting on a system, a hard error[RFC1122] in replied ICMP could serve as a trigger for the fallback process. When the ICMP soft error is present or non- Chen, et al. Expires December 25, 2014 [Page 8] Internet-Draft happy-eyeballs-mif June 2014 response was received, it's recommended that the timeout should be large enough to allow connection retransmission. [RFC1122] states that such timer MUST be at least 3 minutes to provide TCP retransmission. Several minutes delay may not inappropriate for user experiences. A widespread practice[RFC5461] sets 75 seconds to optimize connection process. More optimal timer may be expected. The particular setting will be very specific to implementations and cases. The memo didn't try to provide a concrete value due to following concerns. o RTT(Round-Trip Time) on different interfaces may vary quite a lot. A particular value of timeout may not accurately help to make a decision that this interface doesn't work at all. On the contrary, it may cause a misjudgment on a interface, which is not very fast. In order to compensate the issues, the timeout setting based on past experiences of a particular interface may help to make a fair decision. Whereas, it's going beyond the capability of Happy Eyeballs [RFC6555]. Therefore, it leaves a particular implementation. o In some cases, fast interface may not be treated as "best". For example, a interface could be evaluated in the principle of bandwidth-delay, termed "Bandwidth-Delay-Product ". Happy Eyeballs measures only connection speed. That is, how quickly a TCP connection is established . It does not measure bandwidth. If the fallback has to take various factors into account and make balanced decision, it's better to resort to a specific context and implementation. 6.3. DNS Selections In the sort process, HE-MIF prioritizes PVD-ID match or [RFC6731]inputs to select a proper server. It could help to address following two cases. o A DNS answer may be only valid on a specific provisioning domain, but DNS resolver may not be aware of that because DNS reply is not kept with the provisioning from which the answer comes. The situation may become worse if asking internal name with public address response or asking public name with private address answers. o Some FQDNs can be resolvable only by sending queries to the right server (e.g., intranet services). Otherwise, a response with NXDOMAIN is replied. Fast response is treated as optimal only if the record is valid. That may cause messy for data connections, since NXDOMAIN doesn't provide useful information. Chen, et al. Expires December 25, 2014 [Page 9] Internet-Draft happy-eyeballs-mif June 2014 By doing HE-MIF, it can help to solve the issues of DNS interception with captive portal. The DNS server modified and replied the answer with the IP address of captive portal rather than the intended destination address. In those cases, TCP connection may succeed, but Internet connectivity is not available. It results in lack of service unless user has authenticated. HE-MIF recommended using network connectivity status probes to examine a pre-configured URL for detecting DNS interception on the path (see more in Section 4.2). The node will be able to automatically rely upon other interfaces to select right DNS servers by excluding the unexamined interfaces. 6.4. Flow Continuity Interface changing should only happen at the beginning of new session in order to keep flow continuity for ongoing TCP session. Dynamic movement of traffic flows are beyond the scope of this document. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations The security consideration is following the statement in [RFC6555]and [RFC6418]. 9. Acknowledgements The authors would like to thank Margaret Wasserman, Hui Deng, Erik Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon Perreault, Zhen Cao, Dmitry Anipko and Ted Lemon for their helpful comments. 10. References 10.1. Normative References [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012. Chen, et al. Expires December 25, 2014 [Page 10] Internet-Draft happy-eyeballs-mif June 2014 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved Recursive DNS Server Selection for Multi-Interfaced Nodes", RFC 6731, December 2012. 10.2. Informative References [I-D.ietf-mif-api-extension] Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API consideration", draft-ietf-mif-api-extension-05 (work in progress), February 2014. [I-D.ietf-mif-mpvd-arch] Anipko, D., "Multiple Provisioning Domain Architecture", draft-ietf-mif-mpvd-arch-01 (work in progress), May 2014. [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009. [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011. [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011. Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: phdgang@gmail.com Chen, et al. Expires December 25, 2014 [Page 11] Internet-Draft happy-eyeballs-mif June 2014 Carl Williams Consultant El Camino Real Palo Alto, CA 94306 USA Email: carlw@mcsr-labs.org Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: dwing@cisco.com Andrew Yourtchenko Cisco Systems, Inc. De Kleetlaan, 7 Diegem B-1831 Belgium Email: ayourtch@cisco.com Chen, et al. Expires December 25, 2014 [Page 12]