Internet Engineering Task Force G. Chen
Internet-Draft China Mobile
Intended status: Informational C. Williams
Expires: January 10, 2013 Consultant
D. Wing
A. Yourtchenko
Cisco Systems, Inc.
July 9, 2012
Happy Eyeballs Extension for Multiple Interfaces
draft-ietf-mif-happy-eyeballs-extension-00
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 according to defined policy set of interfaces. This
would choose "best" 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 January 10, 2013.
Copyright Notice
Copyright (c) 2012 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 January 10, 2013 [Page 1]
Internet-Draft happy-eyeballs-mif July 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Happiness Parameters . . . . . . . . . . . . . . . . . . . . . 5
4. HE Behaviour 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. Flow Continuity . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Chen, et al. Expires January 10, 2013 [Page 2]
Internet-Draft happy-eyeballs-mif July 2012
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 optimal
path to connect a server. That is a good method to achieve smart
path selection. However, the assumption there is a single-homed
context. The interaction with multiple interfaces is deferred for
further study.
This memo has been proposed to extend happy eyeballs algorithm to fit
into multiple interfaces context. Several additional considerations
have been elaborated to analyze the user demands and initiate HE-MIF
connections. This document describes a two-stage algorithm, which
should allow a node with multiple interfaces both pick a satisfactory
flow path, and identify the appropriate IP address family.
2. Problem Statement
The section enumerates several concrete use cases in existing
networks.
Case 1: WiFi is broken
o [Scenario] A MIF node has both 3G 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
could be an authentication required coming into play, or unstable
Layer 2 conditions. In order to figure out the problems, users
have to go and 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
Chen, et al. Expires January 10, 2013 [Page 3]
Internet-Draft happy-eyeballs-mif July 2012
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. That 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. One solution is to perform
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. Apart from wifi link, there are some other links involved
on the tethered phone, e.g. 3G access.
o [Problem] The WiFi link that tethered phone see is not free WiFi
link, i.e. it might be 3G 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 3G 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 3G access simultaneously. In
mobile network, IPv6-only may be preferable since IPv6 has the
potential to be simpler than dual-stack. WiFi access still remain
on IPv4.
Chen, et al. Expires January 10, 2013 [Page 4]
Internet-Draft happy-eyeballs-mif July 2012
o [Problem] The problem is caused by policy confliction. The
transition to IPv6 is likely to encourage IPv6 and prefer
IPv6[RFC3484]. If the 3G 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.
3. Happiness Parameters
To solve the problems, this section provide 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 this two-stage 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 behaviour 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 potential users would directly use
those.
* Operator policies: 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).
* Application constraints: applications would express preferences
which may not have a formally technical language , like "No 3G
while roaming", "Only use free WiFi", etc.
o Soft set: It's a factor contributing to the best path. The
following is considered as for the justification.
* Next hop: [RFC4191] and DHCPv6 Route Option
[I-D.ietf-mif-dhcpv6-route-option] allow configuration of
specific routes to a destination.
Chen, et al. Expires January 10, 2013 [Page 5]
Internet-Draft happy-eyeballs-mif July 2012
* DNS selection: [I-D.ietf-mif-dns-server-selection] could
configure nodes with information to indicate DNS server address
for a particular namespace.
* Source address selection: the information provided by [RFC3484]
would be considered.
* 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 Behaviour in MIF
Corresponding to the two sets of parameters, an HE-MIF node will take
a two-step approach. One is to do "hard" decision to synthesize
policies from different actors (e.g., users and network operator).
In a nutshell, that is 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 a sorting
behaviour. Those two things are described as following sub-sections.
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 3G
interface to seek high-reliability or security benefits even to
actively turn off WiFi interface. The decision on mergence of
policies may be made by implementation, by node administrators, even
by other standards investigating customer behaviour. However, it's
worth to note that a demand from users may 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 January 10, 2013 [Page 6]
Internet-Draft happy-eyeballs-mif July 2012
4.2. Second Step, Sort
Sort process would guarantee "best" interface selection with fallback
capacities. Two phases normally are involved in a whole session,
i.e. name resolving and data session establishing. Parameters in
Soft set should considered at this stage.
When the node initiates name requests, it should follow the
instruction in [I-D.ietf-mif-dns-server-selection]if DNS server
selection DHCP option is provided. Otherwise, several alternative
behaviour for DNS server selection described in Appendix A of
[I-D.ietf-mif-dns-server-selection]maybe performed.
Once a peer address was resolved, a connection would be intended to
setup. Heading to a destination, a particular interface may comply
with soft parameter configuration, e.g. next hop[RFC4191]
[I-D.ietf-mif-dhcpv6-route-option], source address selection[RFC3484]
or common practice. A particular interface should be treated with
higher priority compared to others. And, it should be choose to
initiate the connection in advance. This could avoid thrashing the
network, by not (always) making simultaneous connection attempts on
multiple interfaces. After making a connection attempt on the
preferred interface 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 interface.
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 filmily states. So
long as new connections are being attempted by the MIF-node, such an
implementation should occasionally make connection attempts using the
soft-parameter's preferred interface, as it may have become
functional again.
If there are no specific soft-parameters provided, all interface
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.
Chen, et al. Expires January 10, 2013 [Page 7]
Internet-Draft happy-eyeballs-mif July 2012
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), it was also described "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
experiences. 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 3G 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 UI. 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-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.
[Editor note:It should be noted that 75 seconds is a worse case if
host can't get UI input or hard error in ICMP. More optimal timer
may need to be defined depending on further investigation.]
Chen, et al. Expires January 10, 2013 [Page 8]
Internet-Draft happy-eyeballs-mif July 2012
6.3. 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 and Teemu Savolainen for their helpful
comments.
10. References
10.1. Normative References
[I-D.ietf-mif-dns-server-selection]
Savolainen, T., Kato, J., and T. Lemon, "Improved
Recursive DNS Server Selection for Multi-Interfaced
Nodes", draft-ietf-mif-dns-server-selection-10 (work in
progress), June 2012.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[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 January 10, 2013 [Page 9]
Internet-Draft happy-eyeballs-mif July 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-00 (work in
progress), March 2012.
[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-04
(work in progress), February 2012.
[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.
[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 January 10, 2013 [Page 10]
Internet-Draft happy-eyeballs-mif July 2012
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 January 10, 2013 [Page 11]