Internet Engineering Task Force G. Chen Internet-Draft China Mobile Intended status: Informational C. Williams Expires: September 29, 2011 Consultant March 28, 2011 Happy Eyeballs Extension for Multiple Interfaces draft-chen-mif-happy-eyeballs-extension-01 Abstract The memo has been proposed to extend happy eyeballs algorithm to fit into multiple interfaces environment. Based on this extended heuristic algorithm, a client with multiple interface could determine the optimal flow path in which specific interface has been chosen. Furthermore, an appropriate IP address family for each interface can be also identified to guarantee user experiences during IPv6 transition period. 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 September 29, 2011. Copyright Notice Copyright (c) 2011 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Chen & Williams Expires September 29, 2011 [Page 1] Internet-Draft happy-eyeballs-extension March 2011 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Heuristic Happy Eyeballs Extension Algorithm . . . . . . . . . 3 2.1. The Framework for Extended Algorithm . . . . . . . . . . . 3 2.2. Algorithm for Interface Selection . . . . . . . . . . . . . 4 2.3. IPv4/IPv6 Selection Algorithm for Individual Interface . . 4 2.4. Example of Extended Algorithm . . . . . . . . . . . . . . . 4 3. Additional Considerations . . . . . . . . . . . . . . . . . . . 6 3.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Flow Continuity . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Default Address Selection . . . . . . . . . . . . . . . . . 6 3.4. DNS server Selection . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Chen & Williams Expires September 29, 2011 [Page 2] Internet-Draft happy-eyeballs-extension March 2011 1. Introduction In multiple interface context, the problems raised by hosts with multiple interfaces have been discussed. The MIF problem statement[MIF-PS] has described the various issues when using a MIF node on which multiple interfaces are used and results in wrong domain selection. Happy Eyeballs [HAPPY-EYEBALLS] has described how a dual-stack client can determine the functioning path to a dual- stack server. It's using heuristic algorithm help applications to quickly determine if IPv6 or IPv4 is the most optimal to connect to a server. That is a good method to achieve intelligent path selection. However, the assumption here is single-homed host. The interaction with multiple interfaces is still waiting for further study. This memo has been proposed to extend happy eyeballs algorithm to fit into multiple interfaces environment. That could achieve win-win situation. Based on this extended heuristic algorithm, a client with multiple interface could determine the optimal flow path in which specific interface has been chosen. Furthermore, an appropriate IP address family for each interface can be also identified to guarantee user experiences during IPv6 transition period. 2. Heuristic Happy Eyeballs Extension Algorithm The section details extended Happy Eyeballs algorithm, including new defined data structure, functionalities and example flow. 2.1. The Framework for Extended Algorithm The Figure 1 shows the proposed framework for extended algorithm. +-------------------------------------------+ | Host with multiple interfaces | | | | | | | | P1,I1 P2,I2 P3,I3 ... Pn,In | | +---+ +---+ +---+ ... +---+ | | | | | | | | ... | | | +-----+--------+--------+-------------+-----+ | | | ... | 3G Wifi WiMAX ... ... Figure 1: Multiple Interface Mode for Extended Algorithm Chen & Williams Expires September 29, 2011 [Page 3] Internet-Draft happy-eyeballs-extension March 2011 Each interface will be configured with weighting coefficient, which is composed of pair values. Apart from value P, which is following current definition in [HAPPY-EYEBALLS], value I is defined to indicate preference of interfaces selection. In general, value I is responsible for interface selection; value P is a indication to identify IPv4 or IPv6 family has been preferred. 2.2. Algorithm for Interface Selection According to the definition, applications will take account of value I to identify which interface has been chosen before sending out data packages . Each interface is configured with one value, I. I is served as an indication to identify which interface is preferred for a specific destination or hostname. A positive value indicates preference of specific interface compared to others. The value is justified according to TCP establishment duration. The detailed flow can be found in 2.4. The selection of a particular interface from the viable set implies a selection of one particular network path in preference to other viable paths. The rule here is that the shorter path is the winner. When one interface defeats others, the corresponding value I will be set to positive value. Other interfaces will be set negative value orderly according to caused time for TCP connection, like -1, -2, etc. A value of 0 indicates equal weight for multiple interfaces. In this case, the heuristic connection is not valid for interface selection. After several interface values I have been configured, the traffic flow targeted to specific destination address or hostname will follow this guidance to choose proper interface. When connection problems are occurred to preferred connection, the value I need to be adjusted. The adjustment of value I will do polling-based scheme. the value I corresponding to suboptimal interface will be configured as positive. And previously optimal value I will be set to most- negative. 2.3. IPv4/IPv6 Selection Algorithm for Individual Interface For a specific interface in a dual-stack single interface node, the choice of IP address family relies on Happy Eyeballs algorithm, which is defined in [HAPPY-EYEBALLS]. 2.4. Example of Extended Algorithm The Figure 2 shows example flow for algorithm implemetation,in which a host with three interfaces is demonstrated. It's easy to apply that to more interfaces situation. Chen & Williams Expires September 29, 2011 [Page 4] Internet-Draft happy-eyeballs-extension March 2011 DNS Server Client Server | | | 1. |<--www.example.com DNS query ---1| | 2. |<--www.example.com DNS query ---2| | 3. |<--www.example.com DNS query ---3| | 4. |---DNS response, IP address---->1| | 5. |---DNS response, IP address---->2| | 6. |---DNS response, IP address---->3| | 7. | |1==TCP SYN, IP ====>| 8. | |2==TCP SYN, IP ====>| 9. | |3==TCP SYN, IP ====>| 10. | |1 <=TCP SYN+ACK, IP==| 11. | |2 <=TCP SYN+ACK, IP==| 12. | |3 <=TCP SYN+ACK, IP==| 13. | |1==TCP ACK, IP =====>| 14. | |2==TCP ACK, IP =====>| 15. | |3==TCP ACK, IP =====>| 16. | |2--TCP RST, IP------>| 17. | |3--TCP RST, IP------>| Figure 2: Example of Algorithm Execution The example above shows the algorithm execution with emphasis on the computation of coefficient value I. The value P will be calculated as defined in [HAPPY-EYEBALLS]. When the client initiates an application session, multiple interfaces will perform a DNS query simultaneously. As a result, DNS server will return IP address related to requested FQDN, as shown from step 1 to 6. Afterwards, three interfaces are trying to establish TCP connection with remote peer IP address synchronously as shown from step 7 to 15. In this example, interface 1 competes with another two and firstly finish TCP connection. So value I will be set to 1. And second one is set to -1; the last one is set to -2. The interface 2 and 3 will then send RST to remote IP peer for release TCP sessions. IP defined in the diagram is the addresses resulting from the DNS query. In the case of both IPv4 and IPv6 addresses returned from the DNS query for the destination host, the algorithm defined in [HAPPY-EYEBALLS] is used. As described earlier which ever interface results in the fastest TCP connection setup wins and the IP address type that was used for connection setup is the one that will be selected. At the end of the whole process, interface 1 will be set to most- preferred interface for a specific this particular destination or hostname. if there is an accidental connection problem has occurred, Chen & Williams Expires September 29, 2011 [Page 5] Internet-Draft happy-eyeballs-extension March 2011 the value I with interface 1 will be set to -2. And the values I related to interface 2 and 3 will increase sequentially to be set to 1 and -1. Subsequent traffic will take interface 2 as preferred interface for traffic delivery. By providing the IPv6 3. Additional Considerations 3.1. Usage Scope Happy Eyeballs is trageting to HTTP context, but it is useful and applicable to other time-sensitive applications. 3.2. Flow Continuity Usually, interface changing happens at the beginning of new session. So, there is no flow continuity issues for ongoing TCP sesson. Dynamic movement of traffic flows are addressed by other IETF protocols as well. 3.3. Default Address Selection If more than one IPv6 address is assigned to the interface, the native IPv6 address is given preference. 3.4. DNS server Selection The extended Eyeballs algortihm for described herein is independent of DNS server selection routings implemented on the multi-interface client. The DNS queries will be triggered to those DNS servers per policy and methods of the MIF client and the extended MIF enabled Eyeballs extensions work regardless. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations TBD 6. Normative References [HAPPY-EYEBALLS] Wing, D., "Happy Eyeballs: Trending Towards Success with Chen & Williams Expires September 29, 2011 [Page 6] Internet-Draft happy-eyeballs-extension March 2011 Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-00.txt (work in progress), March 2011. [MIF-PS] Blanchet, M., "Multiple Interfaces and Provisioning Domains Problem Statement", draft-ietf-mif-problem-statement-09.txt (work in progress), October 2010. Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: chengang@chinamobile.com Carl Williams Consultant El Camino Real Palo Alto, CA 94306 USA Email: carlw@mcsr-labs.org Chen & Williams Expires September 29, 2011 [Page 7]