idnits 2.17.1 draft-chen-mif-happy-eyeballs-extension-04.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 (March 12, 2012) is 4418 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-mif-dhcpv6-route-option-04 == Outdated reference: A later version (-12) exists of draft-ietf-mif-dns-server-selection-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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: September 13, 2012 Consultant 6 D. Wing 7 A. Yourtchenko 8 Cisco Systems, Inc. 9 March 12, 2012 11 Happy Eyeballs Extension for Multiple Interfaces 12 draft-chen-mif-happy-eyeballs-extension-04 14 Abstract 16 The memo has been proposed to extend happy eyeballs algorithm to fit 17 into multiple interfaces environment. Based on this extended 18 heuristic algorithm, a client with multiple interface could determine 19 the optimal flow path in which specific interface has been chosen. 20 Furthermore, an appropriate IP address family for each interface can 21 be also identified to guarantee user experiences during IPv6 22 transition period. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 13, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Heuristic Happy Eyeballs Extension Algorithm . . . . . . . . . 3 60 2.1. The Framework for Extended Algorithm . . . . . . . . . . . 3 61 2.2. Happiness Parameters . . . . . . . . . . . . . . . . . . . 4 62 2.3. Requirements for Implementations . . . . . . . . . . . . . 5 63 2.4. MIF HE Data Processing . . . . . . . . . . . . . . . . . . 5 64 2.5. IPv4/IPv6 Selection Algorithm for Individual Interface . . 6 65 3. Additional Considerations . . . . . . . . . . . . . . . . . . . 6 66 3.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Flow Continuity . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Default Address Selection . . . . . . . . . . . . . . . . . 6 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 In multiple interface context, the problems raised by hosts with 77 multiple interfaces have been discussed. The MIF problem 78 statement[I-D.ietf-mif-problem-statement] has described the various 79 issues when using a MIF node on which multiple interfaces are used 80 and results in wrong domain selection. Happy Eyeballs 81 [I-D.ietf-v6ops-happy-eyeballs] has described how a dual-stack client 82 can determine the functioning path to a dual-stack server. It's 83 using heuristic algorithm help applications to quickly determine if 84 IPv6 or IPv4 is the most optimal to connect to a server. That is a 85 good method to achieve intelligent path selection. However, the 86 assumption here is single-homed host. The interaction with multiple 87 interfaces is still waiting for further study. 89 This memo has been proposed to extend happy eyeballs algorithm to fit 90 into multiple interfaces environment. That could achieve win-win 91 situation. Based on this extended heuristic algorithm, a client with 92 multiple interface could determine the optimal flow path in which 93 specific interface has been chosen. Furthermore, an appropriate IP 94 address family for each interface can be also identified to guarantee 95 user experiences during IPv6 transition period. 97 2. Heuristic Happy Eyeballs Extension Algorithm 99 The section details extended Happy Eyeballs algorithm, including 100 defined framework, interface weighting consideration and and 101 computation process. 103 2.1. The Framework for Extended Algorithm 105 The Figure 1 shows the proposed framework for extended algorithm. 107 +-------------------------------------------------------+ 108 | +-------------+ +---------+ | 109 | | |---define "Happiness"----->| | | 110 | |Applications | | Kernel | | 111 | | |-make a "H.E." connection->| | | 112 | +-------------+ +---------+ | 113 | | 114 | P1,I1 P2,I2 P3,I3 ... Pn,In | 115 +--------+--------+--------+-------------+--------------+ 116 3G Wifi WiMAX ... ... 118 MIF Happy Eyeballs Framework 120 Therein, several "Happiness" parameters have been defined and feeded 121 into applications. Applications would carry the parameters when they 122 initiate the H.E. conncetion to remote peers. Different parameter 123 sets would be chosen corresponding various demands from service or 124 customer. The parameters should be understable by kernel. And 125 respective system calls would be launched to choose an optimal 126 interface. Regarding the interface selection, each interface will be 127 configured with weighting coefficient, which is composed of pair 128 values. Apart from value P, which is following current definition in 129 [I-D.ietf-v6ops-happy-eyeballs], value I is defined to indicate 130 preference of interfaces selection. In general, value I is 131 responsible for interface selection; value P is a indication to 132 identify IPv4 or IPv6 family has been preferred. 134 2.2. Happiness Parameters 136 The happiness parameters could be categorized in two groups. 138 o Hard preconditions: It's madatory indications that interface 139 behaviour should comply with such preconditions guidance. The 140 following factors belong to hard preconditions. 142 * Operator policies: operators would deliver the customized 143 policies in particular network environments due to charging or 144 area regulation considerations. 146 * User preferences: Users might configure to enable a specific 147 interface to access network. for example, user may choose wifi 148 interface to surf Internet considering low cost. 150 o Soft preconditions: It's optimal choice for transmitting data 151 packages through a specific interface compared to others. The 152 following factors would contribute soft preconditions 153 justification. 155 o 157 * Routing policies: DHCPv6 Route Option 158 [I-D.ietf-mif-dhcpv6-route-option] and RFC4191[RFC4191] allow 159 configuration of specific routes and influence a nodes' ability 160 to pick an appropriate route to a destination. A weighting for 161 an interface headed to destination address that matches a 162 specific route would be increased. 164 * DNS selection: if improved DNS server selection 165 [I-D.ietf-mif-dns-server-selection] takes effects, the wighting 166 for those interfaces over which DNS suffix matching the 167 requested name should also be increased. 169 * Other factors: There are many other factors could contribute 170 optimal interface selection. This documents would like to 171 focus on the main ones and treat others in a best effort 172 manner. The key factors are expected to be added in future 173 discussion. 175 2.3. Requirements for Implementations 177 The implementations of MIF HE modules should have a good transparency 178 for applications and system kernel . The modules is responsible for 179 two functionalities, i.e. HE syntax resolving and HE connection 180 initiation . HE syntax resolving is capable of analyzing application 181 demands and mapping to H.E. parameters. Resolved parameter may 182 include "Hard" or "Soft" preconditions which are indicated in section 183 2.2. Afterwards, "Filter" and "Sort" are rules applied to make a 184 step-wise processing . Depending on the judgement, the modules would 185 initiate the connection to system kernel and choose a proper 186 interface. 188 2.4. MIF HE Data Processing 190 According to the definition, applications would pass happiness 191 parameters to kernel. Afterwards, system call would take account of 192 value I to identify which interface has been chosen before sending 193 out data packages . 195 The selection of a particular interface from the viable set implies a 196 selection of one particular network path in preference to other 197 viable paths. Interface weighting must be computed in advance but 198 also be recomputed during session. The whole process for interface 199 selection would offer the paramters with two kinds of priorities. 201 At stage I, upon the connection attempt, hard preconditions would be 202 filtered , and then aggregate the results within that kind of "policy 203 group". 205 At stage II, the soft preconditions should be applied to the resulted 206 inteface set. According to particular soft preconditions, the 207 prefered interface would be chosen by increasing I and delaying the 208 connection attempts on the "undesirable" interfaces. This would 209 allow to dial the preference between the different interfaces. The 210 less desirable interface would get penalised a-priori. 212 When one interface defeats others, the corresponding value I will be 213 set to positive value. Other interfaces will be set negative value. 214 A value of 0 indicates equal weight for multiple interfaces. 216 When interface values I have been configured, the traffic flow 217 targeted to specific destination address or hostname will follow this 218 guidance to choose proper interface. Hence, initial connection 219 attempt would be sent over the interface that has matching particular 220 rules and other interfaces would be tried only if no reply on the 221 preferred one. Network condition may change during the session, 222 interface reselection should be triggered. When connection problems 223 are occurred to preferred connection, the value I need to be 224 adjusted. The adjustment of value I will do polling-based scheme. 225 The value I corresponding to suboptimal interface will be configured 226 as positive. And previously optimal value I will be set to most- 227 negative. 229 2.5. IPv4/IPv6 Selection Algorithm for Individual Interface 231 For a specific interface in a dual-stack single interface node, the 232 choice of IP address family relies on Happy Eyeballs algorithm, which 233 is defined in [I-D.ietf-v6ops-happy-eyeballs]. 235 3. Additional Considerations 237 3.1. Usage Scope 239 Happy Eyeballs is trageting to HTTP context, but it is useful and 240 applicable to other time-sensitive applications. 242 3.2. Flow Continuity 244 Usually, interface changing happens at the beginning of new session. 245 So, there is no flow continuity issues for ongoing TCP sesson. 246 Dynamic movement of traffic flows are addressed by other IETF 247 protocols as well. 249 3.3. Default Address Selection 251 If more than one IPv6 address is assigned to the interface, the 252 native IPv6 address is given preference. 254 4. IANA Considerations 256 This memo includes no request to IANA. 258 5. Security Considerations 260 TBD 262 6. Normative References 264 [I-D.ietf-mif-dhcpv6-route-option] 265 Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 266 Route Options", draft-ietf-mif-dhcpv6-route-option-04 267 (work in progress), February 2012. 269 [I-D.ietf-mif-dns-server-selection] 270 Kato, J., Lemon, T., and T. Savolainen, "Improved DNS 271 Server Selection for Multi-Interfaced Nodes", 272 draft-ietf-mif-dns-server-selection-07 (work in progress), 273 October 2011. 275 [I-D.ietf-mif-problem-statement] 276 Blanchet, M. and P. Seite, "Multiple Interfaces and 277 Provisioning Domains Problem Statement", 278 draft-ietf-mif-problem-statement-15 (work in progress), 279 May 2011. 281 [I-D.ietf-v6ops-happy-eyeballs] 282 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 283 Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-07 284 (work in progress), December 2011. 286 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 287 More-Specific Routes", RFC 4191, November 2005. 289 Authors' Addresses 291 Gang Chen 292 China Mobile 293 53A,Xibianmennei Ave., 294 Xuanwu District, 295 Beijing 100053 296 China 298 Email: phdgang@gmail.com 300 Carl Williams 301 Consultant 302 El Camino Real 303 Palo Alto, CA 94306 304 USA 306 Email: carlw@mcsr-labs.org 307 Dan Wing 308 Cisco Systems, Inc. 309 170 West Tasman Drive 310 San Jose, CA 95134 311 USA 313 Email: dwing@cisco.com 315 Andrew Yourtchenko 316 Cisco Systems, Inc. 317 El Camino Real 318 De Kleetlaan, 7 Diegem B-1831 319 Belgium 321 Email: ayourtch@cisco.com