Internet Engineering Task Force G. Chen
Internet-Draft China Mobile
Intended status: Informational C. Williams
Expires: April 3, 2012 Consultant
D. Wing
A. Yourtchenko
Cisco Systems, Inc.
Oct 2011
Happy Eyeballs Extension for Multiple Interfaces
draft-chen-mif-happy-eyeballs-extension-03
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 April 3, 2012.
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
Chen, et al. Expires April 3, 2012 [Page 1]
Internet-Draft happy-eyeballs-extension Oct 2011
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
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.
Chen, et al. Expires April 3, 2012 [Page 2]
Internet-Draft happy-eyeballs-extension Oct 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Heuristic Happy Eyeballs Extension Algorithm . . . . . . . . . 4
2.1. The Framework for Extended Algorithm . . . . . . . . . . . 4
2.2. Happiness Parameters . . . . . . . . . . . . . . . . . . . 5
2.3. HE Data Processing . . . . . . . . . . . . . . . . . . . . 6
2.4. IPv4/IPv6 Selection Algorithm for Individual Interface . . 7
3. Additional Considerations . . . . . . . . . . . . . . . . . . . 7
3.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Flow Continuity . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Default Address Selection . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Chen, et al. Expires April 3, 2012 [Page 3]
Internet-Draft happy-eyeballs-extension Oct 2011
1. Introduction
In multiple interface context, the problems raised by hosts with
multiple interfaces have been discussed. The MIF problem
statement[I-D.ietf-mif-problem-statement] has described the various
issues when using a MIF node on which multiple interfaces are used
and results in wrong domain selection. Happy Eyeballs
[I-D.ietf-v6ops-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
defined framework, interface weighting consideration and and
computation process.
2.1. The Framework for Extended Algorithm
The Figure 1 shows the proposed framework for extended algorithm.
+-------------------------------------------------------+
| +-------------+ +---------+ |
| | |---define "Happiness"----->| | |
| |Applications | | Kernel | |
| | |-make a "H.E." connection->| | |
| +-------------+ +---------+ |
| |
| P1,I1 P2,I2 P3,I3 ... Pn,In |
+--------+--------+--------+-------------+--------------+
3G Wifi WiMAX ... ...
Figure 1: Framework
Therein, several "Happiness" parameters have been defined and feeded
Chen, et al. Expires April 3, 2012 [Page 4]
Internet-Draft happy-eyeballs-extension Oct 2011
into applications. Applications would carry the parameters when they
initiate the H.E. conncetion to remote peers. Different parameter
sets would be chosen corresponding various demands from service or
customer. The parameters should be understable by kernel through
defined MIF API. And respective system calls would be launched to
choose an optimal interface. Regarding the interface selection, each
interface will be configured with weighting coefficient, which is
composed of pair values. Apart from value P, which is following
current definition in [I-D.ietf-v6ops-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. Happiness Parameters
The happiness parameters could be categorized in two groups.
o Hard preconditions: It's madatory indications that interface
behaviour should comply with such preconditions guidance. The
following factors belong to hard preconditions.
o
* Operator policies: operators would deliver the customized
policies in particular network environments due to charging or
area regulation considerations.
* User preferences: Users might configure to enable a specific
interface to access network. for example, user may choose wifi
interface to surf Internet considering low cost.
o Soft preconditions: It's optimal choice for transmitting data
packages through a specific interface compared to others. The
following factors would contribute soft preconditions
justification.
o
* Routing policies: DHCPv6 Route Option
[I-D.ietf-mif-dhcpv6-route-option] and RFC4191[RFC4191] allow
configuration of specific routes and influence a nodes' ability
to pick an appropriate route to a destination. A weighting for
an interface headed to destination address that matches a
specific route would be increased.
* DNS selection: if improved DNS server selection
[I-D.ietf-mif-dns-server-selection] takes effects, the wighting
for those interfaces over which DNS suffix matching the
Chen, et al. Expires April 3, 2012 [Page 5]
Internet-Draft happy-eyeballs-extension Oct 2011
requested name should also be increased.
* Other factors: There are many other factors could contribute
optimal interface selection. This documents would like to
focus on the main ones and treat others in a best effort
manner. The key factors are expected to be added in future
discussion.
2.3. HE Data Processing
According to the definition, applications would pass happiness
parameters to kernel. Afterwards, system call would take account of
value I to identify which interface has been chosen before sending
out data packages .
The selection of a particular interface from the viable set implies a
selection of one particular network path in preference to other
viable paths. Interface weighting must be computed in advance but
also be recomputed during session. The whole process for interface
selection would offer the paramters with two kinds of priorities.
At stage I, upon the connection attempt, hard preconditions would be
filtered , and then aggregate the results within that kind of "policy
group".
At stage II, the soft preconditions should be applied to the resulted
inteface set. According to particular soft preconditions, the
prefered interface would be chosen by increasing I and delaying the
connection attempts on the "undesirable" interfaces. This would
allow to dial the preference between the different interfaces. The
less desirable interface would get penalised a-priori.
When one interface defeats others, the corresponding value I will be
set to positive value. Other interfaces will be set negative value.
A value of 0 indicates equal weight for multiple interfaces.
When interface values I have been configured, the traffic flow
targeted to specific destination address or hostname will follow this
guidance to choose proper interface. Hence, initial connection
attempt would be sent over the interface that has matching particular
rules and other interfaces would be tried only if no reply on the
preferred one. Network condition may change during the session,
interface reselection should be triggered. 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.
Chen, et al. Expires April 3, 2012 [Page 6]
Internet-Draft happy-eyeballs-extension Oct 2011
2.4. 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 [I-D.ietf-v6ops-happy-eyeballs].
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.
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
TBD
6. Normative References
[I-D.ietf-mif-dhcpv6-route-option]
Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6
Route Options", draft-ietf-mif-dhcpv6-route-option-03
(work in progress), September 2011.
[I-D.ietf-mif-dns-server-selection]
Savolainen, T., Kato, J., and T. Lemon, "Improved DNS
Server Selection for Multi-Interfaced Nodes",
draft-ietf-mif-dns-server-selection-07 (work in progress),
Chen, et al. Expires April 3, 2012 [Page 7]
Internet-Draft happy-eyeballs-extension Oct 2011
October 2011.
[I-D.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement",
draft-ietf-mif-problem-statement-15 (work in progress),
May 2011.
[I-D.ietf-v6ops-happy-eyeballs]
Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-05
(work in progress), October 2011.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
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
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: dwing@cisco.com
Chen, et al. Expires April 3, 2012 [Page 8]
Internet-Draft happy-eyeballs-extension Oct 2011
Andrew Yourtchenko
Cisco Systems, Inc.
El Camino Real
De Kleetlaan, 7 Diegem B-1831
Belgium
Email: ayourtch@cisco.com
Chen, et al. Expires April 3, 2012 [Page 9]