< draft-ietf-mif-happy-eyeballs-extension-07.txt   draft-ietf-mif-happy-eyeballs-extension-08.txt >
Internet Engineering Task Force G. Chen Internet Engineering Task Force G. Chen
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational C. Williams Intended status: Informational C. Williams
Expires: April 19, 2016 Consultant Expires: June 22, 2016 Consultant
D. Wing D. Wing
A. Yourtchenko A. Yourtchenko
Cisco Systems, Inc. Cisco Systems, Inc.
October 17, 2015 December 20, 2015
Happy Eyeballs Extension for Multiple Interfaces Happy Eyeballs Extension for Multiple Interfaces
draft-ietf-mif-happy-eyeballs-extension-07 draft-ietf-mif-happy-eyeballs-extension-08
Abstract Abstract
Currently the interface selection in multi-interface environment is This memo proposes extensions to the Happy Eyeball(HE) defined in
exclusive - only one interface can be used at the time, frequently RFC6555 and fit into a multiple provisioning domain architecture.
needing manual intervention. Happy Eyeballs in MIF would make the Happy Eyeballs in MIF would make the selection process smoother by
selection process smoother by using the connectivity checks over a using connectivity tests over pre-filtered interfaces according to
pre-filtered interfaces according to defined policy. This would defined policy. This would choose the most fast interface with an
choose the fastest interface with an automatic fallback. automatic fallback mechnism.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2016. This Internet-Draft will expire on June 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Happiness Parameters . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. HE Behavior in MIF . . . . . . . . . . . . . . . . . . . . . 4 4. Happiness Parameters . . . . . . . . . . . . . . . . . . . . 4
4.1. First Step, Filter . . . . . . . . . . . . . . . . . . . 5 5. HE-MIF behavior . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Second Step, Sort . . . . . . . . . . . . . . . . . . . . 5 5.1. First Step, Filter . . . . . . . . . . . . . . . . . . . 5
5. Implementation Framework . . . . . . . . . . . . . . . . . . 7 5.2. Second Step, Sort . . . . . . . . . . . . . . . . . . . . 6
6. Additional Considerations . . . . . . . . . . . . . . . . . . 7 6. Implementation Framework . . . . . . . . . . . . . . . . . . 7
6.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . 7 7. Additional Considerations . . . . . . . . . . . . . . . . . . 7
6.2. Fallback Timeout . . . . . . . . . . . . . . . . . . . . 7 7.1. Usage Scope . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. DNS Selections . . . . . . . . . . . . . . . . . . . . . 8 7.2. Fallback Timeout . . . . . . . . . . . . . . . . . . . . 7
6.4. Flow Continuity . . . . . . . . . . . . . . . . . . . . . 9 7.3. DNS Selections . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7.4. Flow Continuity . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
In multiple interface context, the problems raised by hosts with In a multiple interface context, the problems raised by hosts with
multiple interfaces have been discussed. The MIF problem multiple interfaces have been discussed in the MIF problem statement
statement[RFC6418] described the various issues when using a wrong [RFC6418], which describes the various issues when using a wrong
domain selection on a MIF node. Happy Eyeballs (HE) [RFC6555] domain selection on a MIF node. Happy Eyeballs (HE) [RFC6555]
described how a dual-stack client can determine the functioning path describes how a dual-stack client can determine the most fast path to
to a dual-stack server. It's using stateful algorithm to help a dual-stack server by employing a stateful algorithm to quickly
applications quickly determine if IPv6 or IPv4 is the most fast path discover if the IPv4 or IPv6 path is faster. while this is a good
to connect a server. That is a good method to achieve smart path method to achieve smart path selection, it assumes a single-homed
selection. However, the assumption is a single-homed context. The node targeted. Interaction with multiple interfaces was deferred for
interaction with multiple interfaces is deferred for further study. further study.
[RFC7556] has proposed a multiple provisioning domain architecture. [RFC7556] has proposed a multiple provisioning domain architecture.
This memo has been proposed to extend happy eyeballs algorithm to fit This memo proposes extensions to the Happy Eyeball(HE) defined in
into the multiple interfaces architecture. Several additional [RFC6555] to support multiple interfaces, such that a node with
considerations have been elaborated to analyze the user demands and multiple interfaces can choose the most fast path for a particular
initiate HE-MIF connections. It allows a node with multiple connection-oriented flow (e.g., TCP, SCTP).
interfaces picking a fast flow path.
2. Use Cases 2. Terminology
This document makes use of following terms:
o Happy Eyeballs (HE): it specifies requirements for algorithms that
reduce user-visible delay of dual-stack hosts within a single
home.
o HE-MIF: it adopts Happy Eyeballs concept [RFC6555] to the multiple
provisioning domain architecture. It describes requirements for
algorithms that offer connectivity tests on PVD-aware or non-PVD-
aware nodes [RFC7556] to select the most fast interface.
3. Use Cases
The section describes use cases in existing networks. The section describes use cases in existing networks.
Use Case: WiFi is broken Use Case: WiFi is broken
A MIF node has both 3/4G and WiFi interface. When the node enters a Assuming a MIF node has both 3GPP mobile network interface and WiFi
WiFi area, a common practice would always prefer WiFi because it' interface, a common practice would always prefer WiFi connection when
cheap and fast-speed normally. User assumes the WiFi is working, the node enters a WiFi area. In this situation, a node might assume
because the node already got IP address from WiFi. However, he can't the WiFi link can reach destinations on the global Internet, because
run applications due to Internet connectivity being unavailable. a valid IP address has been assigned on the interface. However, this
This may be an authentication required coming into play, or unstable might not be the case for several reasons, such as authentication
Layer 2 conditions. In order to figure out the problems, users have requirements, instability at layer 2, or even, perhaps, the WiFi
to turn off the WiFi manually. With HE-MIF, users can indicate their being connected to a local network with no global Internet
reachability. In order to figure out the problems, a user has to
turn off the WiFi manually. With HE-MIF, users can indicate their
desire with some setting on the phone. For instance, they may prefer 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 to wait an appropriate time slot but not forever. After the timer is
expired, users would finally give up the WiFi path and try to expired, users may finally give up the WiFi path and try to establish
establish connection over 3G path. Users may won't want the wait connection over a 3GPP mobile network path. Users may not want a
time too short, because the 3G path for most people is more expensive very short timer, because the mobile network path for most people is
than WiFi path. more expensive than a WiFi path. An appropriate timer is desired to
balance user experience and expenditure.
Use Case: Policy Conflict Use Case: Policy Conflict
A node has WiFi and 3/4G access simultaneously. In mobile network, A node has both WiFi and 3GPP network access simultaneously. In a
IPv6-only may be preferable since IPv6 has the potential to be mobile network, IPv6-only may be preferable since IPv6 has the
simpler than dual-stack. WiFi access still remains on IPv4. The potential to be simpler than dual-stack. WiFi access still remains
problem is caused by policy confliction. The transition to IPv6 is on IPv4. The problem is caused by source address selection principle
likely to encourage IPv6 and prefer IPv6[RFC6724]. If the 3/4G path [RFC6724] and wifi preference. The transition to IPv6 is likely to
has IPv6 on it and the WiFi does not, a suboptimal interface might be encourage and prefer IPv6 . If a 3GPP network path has IPv6 on it and
chosen from the cost saving perspective. With HE-MIF, users a WiFi does not, the 3GPP interface might be chosen while it maybe a
interests should be well understood and considered before interface suboptimal selection since the wifi interface likely is less
selection. The different preconditions may impact subsequent expensive. With HE-MIF, user's interests could be well understood
behaviors. Users concern about high-reliability or high-speed or and considered before interface selection. Different preconditions
less-cost should make different choice. A flexible mechanism should can impact subsequent behaviors. Users concern about high-
be provided allow to make smart decision. reliability or high-speed or less-cost would make different choicies.
A flexible mechanism is provided to make smart decision.
3. Happiness Parameters 4. Happiness Parameters
This section provides the design proposal for HE-MIF. Two sets of This section provides a design proposal for HE-MIF. Two sets of
"Happiness" parameters have been defined. It serves upper "Happiness" parameters have been defined. It serves applications and
applications and initiates HE-MIF connections to below level API initiates HE-MIF connections tests subsequently. Going through the
subsequently. Going through the process, MIF nodes could pick an process, MIF nodes could pick an appropriate interface which would
appropriate interface which would correspond to user demands. The correspond to user demands. The two sets of "Happiness" parameters
two sets of "Happiness" parameters are called Hard set and Soft set are called Hard Set and Soft Set respectively.
respectively.
o Hard Set: It contains parameters which have mandatory indications o Hard Set: Contains parameters which must be complied with. It
that interface behavior should comply with. This might provide an helps to select candidate interfaces through which a particular
interface for applications constraints or delivering operator's flow should be directed. These should be seen as constraints on
policies. Basically, parameters in Hard set should be easy-to-use the choice, such as provider policies, support for IPv4 or IPv6,
and easy-to-understand. The users would directly use those. When and other parameters which would prevent a particular interface
several hard parameters were conflicted, user's preference should and transport from being used by a particular flow. Parameters in
be prioritized. the hard set should be easy to use and understand. When several
parameters in the hard set are in conflict, the user's preference
should be prioritized.
* User's preference: users would express preferences which may * User's preference: users may express preferences which likely
not have a formally technical language , like "No 3G while not have a formally technical language , like "No 3G while
roaming", "Only use free WiFi", etc. roaming", "Only use free WiFi", etc.
* Operator policy: operators would deliver the customized * Operator policy: operators may deliver the customized policies
policies in particular network environments due to geo-location in a particular network environment because of geo-location or
or services regulation considerations. One example in 3GPP services regulation considerations. One example in 3GPP
network is that operator could deliver policies from access network is that operator could deliver policies from access
network discovery and selection function (ANDSF). network discovery and selection function (ANDSF).
o Soft Set: It contains factors involving in the selection of the o Soft Set: Contains factors which impact the selection of the path
fastest path. The following is considered as for the across which a particular flow should be transmitted among the
justification. available interfaces and transports which meet the hard set
requirements described above. Examples might include:
* PVD-ID (Provisioning Domain Identity): PVD-aware node may * PVD-ID (Provisioning Domain Identity): PVD-aware node may
decide to use one preferred PVD or allow use mulitple PVDs decide to use one preferred PVD or allow use multiple PVDs
simultanenously for applications. The node behavior should be simultaneously for applications. The node behavior should be
consistent with MPVD architecture. consistent with MPVD architecture [RFC7556].
* Next hop: [RFC4191] allows configuration of specific routes to * Next hop: [RFC4191] allows configuration of specific routes to
a destination. a destination.
* DNS selection: [RFC6731] could configure nodes with information * DNS selection: [RFC6731] could configure nodes with information
to indicate DNS server address for a particular namespace. to indicate a DNS server address for a particular namespace.
* Source address selection: the information provided by [RFC6724] * Source address selection: the information provided by [RFC6724]
would be considered. should be considered.
* Other factors: There is a common practice may impact interface * Other factors: There is a common practice may impact interface
selection, e.g. WiFi is preferable. Such conventional selection, e.g. WiFi is preferable. Such conventional
experiences should also be considered. experiences should also be considered.
4. HE Behavior in MIF 5. HE-MIF behavior
Corresponding to the two sets of parameters, a HE-MIF node may take a 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 two-steps approach. One is to do "Hard" decision to synthesize
policies from different actors (e.g., users and network operator). policies from different actors (e.g., users and network operator).
In a nutshell, that is a filter which will exclude the interfaces In a nutshell, that is a filter which will exclude the interfaces
from any further consideration. The second is to adjust how we make from any further consideration. The second is to adjust how a node
a connection on multiple interfaces after the filter. It's sorting make a connection on multiple interfaces after the filter. It's
behavior. In the multiple provisioning domain architecture, a PVD sorting behavior. In the multiple provisioning domain architecture,
aware node takes connectivity tests as described in Section 5.3 of a PVD aware node takes connectivity tests as described in Section 5.3
of [RFC7556]. A PVD agnostic node take other parameters in the Soft
[RFC7556]. A PVD agnostic node take other parameters in the Soft Set Set to proceed the sort process.
to proceed the sort process.
Those two steps are described as following sub-sections. It should 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 noted that HE-MIF doesn't prescribe such two-step model. It will
be very specific to particular cases and implementations. For be very specific to particular cases and implementations. For
example, if one interface on a particular PVD is left after the first example, if only one interface is left after the first step, the
step, the process would be ceased. process is likely ceased.
4.1. First Step, Filter 5.1. First Step, Filter
One goal of filter is to reconcile multiple selection policies from One goal of the filter is to reconcile multiple selection policies
users or operators. Afterwards, the merged demands would be mapped from users or operators. Afterwards, merged demands would be mapped
to a set of candidate interfaces, which is judged as qualified. to a set of candidate interfaces, which is judged as qualified.
Decision on reconciliation of different policies will depend very Decision on reconciliation of different policies will depend very
much on the deployment scenario. An implementation may not be able much on the deployment scenario. An implementation may not be able
to determine priority for each policies without explicit to determine priority for each policies without explicit
configuration provided by users or administrator. For example, an configuration provided by users or administrator. For example, an
implementation may by default always prefer the WiFi due to cost implementation may by default always prefer the WiFi because of cost
saving consideration. Whereas, users may dedicatedly prefer 3/4G saving consideration. Whereas, users may dedicatedly prefer a 3GPP
interface to seek high-reliability or security benefits even to network interface to seek high-reliability or security benefits even
manually turn off WiFi interface. The decision on mergence of to manually turn off WiFi interface. The decision on mergence of
policies may be made by implementations, by node administrators, even policies may be made by implementations, by node administrators, even
by other standards investigating customer behavior. However, it's by other standards investigating customer behavior. However, it's
worth to note that a demand from users should be normally considered worth to note that a demand from users should be normally considered
higher priority than from other actors. higher priority than from other actors.
The merged policies would serve as a filter principle doing iterate The merged policies would serve as a filter principle doing iterate
across the list of all known interfaces. Qualified interface would across the list of all known interfaces. Qualified interface would
be selected to sort processing at next step. be selected to Sort processing at the next step.
4.2. Second Step, Sort 5.2. Second Step, Sort
Sort process guarantees fast interface selection with fallback A Sort process guarantees a fast interface selection with fallback
capacities. As stated in [RFC7556], a PVD-aware node shall perform capacities. As stated in [RFC7556], a PVD-aware node shall perform
connectivity test and, only after validation of the PVD, consider connectivity test and, only after validation of the PVD, consider
using it to serve application connections requests. A common using it to serve application connections requests. In current
practise is to probe a pre-configured URL to check network implementations, some nodes already implement this, e.g., by trying
connectivity status as soon as a node access a network at bootstrap to reach a dedicated web server (see [RFC6419] ). If anything is
or changes to different networks, e.g. Windows Vista, Windows 7, abnormal, it assumes there is a proxy on the path. This status
Windows Server 2008 and iOS. If anything is abnormal, it assumes detection is recommended to be used in HE-MIF to detect DNS
there is a proxy on the path. This status detection is recommended interception or HTTP proxy that forces a login or a click-through.
to be used in HE-MIF to detect DNS interception or HTTP proxy that Unexamined PVDs or interfaces should be accounted as "unconnected".
forces a login or a click-through. Unexamined PVDs or interfaces It should not join the sort process.
should be accounted as "unconnected". It should not join the sort
process.
Afterwards, two phases normally are involved in a sort process, i.e. Afterwards, two phases normally are involved in a Sort process, i.e.,
name resolving and connection establishment. Parameters in a soft name resolving and connection establishment. The Soft set parameters
set should considered at this stage. defined in Section 4 should considered at this stage.
When a node initiates name resolution requests, it should check if When a node initiates name resolution requests, it should check if
there is a matched PVD ID for the destination name. A PVD agnostic there is a matched PVD ID for the destination name. A PVD agnostic
node may request DNS server selection DHCP option[RFC6731] for node may request DNS server selection DHCP option [RFC6731] for
interface selection guidance. Those information may weight a interface selection guidance. Those information may weight a
particular interface to be preferred one prior to others sending particular interface to be preferred to others sending resolving
resolving requests. If the node can't find useful information in the requests. If the node can't find useful information in the Soft Set,
Soft Set, DNS queries would be sent out on multiple interfaces on DNS queries would be sent out on multiple interfaces in parallel to
relevant PVDs in parallel to maximize chances for connectivity. Some maximize chances for connectivity. Some additional discussions of
additional discussions of DNS selection consideration of HE-MIF are DNS selection consideration of HE-MIF are described in Section 7.3.
described in Section 6.3.
Once a destination address was resolved, a connection is to be setup. Once a destination address was resolved, a connection is to be setup.
For the given destination address, a PVD-aware node selects a next- For the given destination address, a PVD-aware node selects a next-
hop and source address associated with that PVD in the name hop and source address associated with that PVD in the name
resolution process. A PVD agnostic node may receive certain next hop resolution process. A PVD agnostic node may receive certain next hop
in RA message[RFC4191] , the node selects best source address in a RA message [RFC4191], the node selects best source address
according to the[RFC6724] rules. When destination and source pairs according to the rules [RFC6724]. When destination and source pairs
are identified, it should be treated with higher priority compared to are identified, it should be treated with higher priority compared to
others and choose to initiate the connection in advance. This could others and choose to initiate the connection in advance. This could
avoid thrashing the network, by not making simultaneous connection avoid thrashing the network, by not making simultaneous connection
attempts on multiple interfaces. After making a connection attempt attempts on multiple interfaces. After making a connection attempt
on the preferred pairs and failing to establish a connection within a on the preferred pairs and failing to establish a connection within a
certain time period (see Section 6.2), a HE-MIF implementation will certain time period (see Section 7.2), a HE-MIF implementation will
decide to initiate connection attempt using rest of interfaces in decide to initiate connection attempt using rest of interfaces in
parallel. This fallback consideration may make subsequent connection parallel. This fallback consideration will make subsequent
attempts successful on non-preferable interfaces. connection attempts successful on non-preferable interfaces.
The node would cache information regarding the outcome of each The node would cache information regarding the outcome of each
connection attempt. Cache entries would be flushed periodically. A connection attempt. Cache entries would be flushed periodically. A
system-defined timeout may take place to age the state. Maximum on 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 order of 10 minutes defined in [RFC6555] is recommended to keep
the interface state changes synchronizing with IP family states. the interface state changes synchronizing with IP family states.
If there are no specific Soft Set provided, all selected interfaces If there are no specific Soft Set provided, all selected interfaces
should be equally treated. The connections would initiate on several should be equally treated. The connections would initiate on several
interface simultaneously. The goal here is to provide fast interface simultaneously. The goal here is to provide the most fast
connection for users, by quickly attempting to connect using one of connection for users, by quickly attempting to connect using each
interfaces. Afterwards, the node would do the same caching and candidate interface. Afterwards, the node would do the same caching
flushing process as described above. and flushing process as described above.
5. Implementation Framework 6. Implementation Framework
The simplest way for the implementation is within the application The simplest way for the implementation is within the application
itself. The mechanism described in the document would not require itself. The mechanism described in the document would not require
any specific support from the operating system beyond the commonly any specific support from the operating system beyond the commonly
available APIs that provide transport service. It could also be available APIs that provide transport service. It could also be
implemented as high-level API approach, linking to MIF-API implemented as high-level API approach, linking to MIF-API
[I-D.ietf-mif-api-extension]. A number of enhancements could be [I-D.ietf-mif-api-extension].
added, making the use of the high-level APIs much more productive in
building applications.
6. Additional Considerations 7. Additional Considerations
6.1. Usage Scope 7.1. Usage Scope
Connection-oriented transports (e.g., TCP, SCTP) could be directly Connection-oriented transports (e.g., TCP, SCTP) are directly applied
applied as scoped in [RFC6555]. For connectionless transport as scoped in [RFC6555]. For connectionless transport protocols
protocols (e.g., UDP), a similar mechanism can be used if the (e.g., UDP), a similar mechanism can be used if the application has
application has request/ response semantics (e.g., as done by request/response semantics. Further investigrations are out of the
Interactive Connectivity Establishment (ICE) to select a working IPv6 document scope.
or IPv4 media path[RFC6157])."
6.2. Fallback Timeout 7.2. Fallback Timeout
When the preferred interface was failed, HE-MIF would trigger When the preferred interface was failed, HE-MIF would trigger a
fallback process to start connection initiation on several candidate fallback process to start connection initiation on several candidate
interfaces. It should set a reasonable wait time to comfort user interfaces. It should set a reasonable wait time to comfort user
experience. Aggressive timeouts may achieve quick interface experience. Aggressive timeouts may achieve quick interface
handover, but at the cost of traffic that may be chargeable on 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 certain networks, e.g. the handover from WiFi to 3GPP networks brings
bill to customers. Considering the reasons, it is recommended to a charge to customers. Considering the reasons, it is recommended to
prioritize the input from users(e.g. real customers or applications) prioritize the input from users (e.g., real customers or
through user interface. For default-setting on a system, a hard applications) through user interface. For default-setting on a
error[RFC1122] in replied ICMP could serve as a trigger for the system, a hard error [RFC1122] in replied ICMP could serve as a
fallback process. When the ICMP soft error is present or non- trigger for the fallback process. When the ICMP soft error is
response was received, it's recommended that the timeout should be present or non-response was received, it's recommended that the
large enough to allow connection retransmission. [RFC1122] states timeout should be large enough to allow connection retransmission.
that such timer MUST be at least 3 minutes to provide TCP [RFC1122] states that such timer MUST be at least 3 minutes to
retransmission. Several minutes delay may not inappropriate for user provide TCP retransmission. However, several minutes delay may not
experiences. A widespread practice[RFC5461] sets 75 seconds to inappropriate for user experiences. A widespread practice [RFC5461]
optimize connection process. sets 75 seconds to optimize connection process.
More optimal timer may be expected. The particular setting will be More optimal timer may be expected. The particular setting will be
very specific to implementations and cases. The memo didn't try to very specific to implementations and cases. The memo didn't try to
provide a concrete value due to following concerns. provide a concrete value because of following concerns.
o RTT(Round-Trip Time) on different interfaces may vary quite a lot. o RTT (Round-Trip Time) on different interfaces may vary quite a
A particular value of timeout may not accurately help to make a lot. A particular value of timeout may not accurately help to
decision that this interface doesn't work at all. On the 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 contrary, it may cause a misjudgment on a interface, which is not
very fast. In order to compensate the issues, the timeout setting very fast. In order to compensate the issues, the timeout setting
based on past experiences of a particular interface may help to based on past experiences of a particular interface may help to
make a fair decision. Whereas, it's going beyond the capability make a fair decision. Whereas, it's going beyond the capability
of Happy Eyeballs [RFC6555]. Therefore, it leaves a particular of Happy Eyeballs [RFC6555]. Therefore, it leaves a particular
implementation. implementation.
o In some cases, fast interface may not be treated as "best". For o In some cases, fast interface may not be treated as "best". For
example, a interface could be evaluated in the principle of example, a interface could be evaluated in the principle of
bandwidth-delay, termed "Bandwidth-Delay-Product ". Happy bandwidth-delay, termed "Bandwidth-Delay-Product ". Happy
Eyeballs measures only connection speed. That is, how quickly a Eyeballs measures only connection speed. That is, how quickly a
TCP connection is established . It does not measure bandwidth. If TCP connection is established . It does not measure bandwidth. If
the fallback has to take various factors into account and make the fallback has to take various factors into account and make
balanced decision, it's better to resort to a specific context and balanced decision, it's better to resort to a specific context and
implementation. implementation.
6.3. DNS Selections 7.3. DNS Selections
In the sort process, HE-MIF prioritizes PVD-ID match or In the Sort process, HE-MIF prioritizes PVD-ID match or
[RFC6731]inputs to select a proper server. It could help to address [RFC6731]inputs to select a proper server. It could help to address
following two cases. following two cases.
o A DNS answer may be only valid on a specific provisioning domain, 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 but DNS resolver may not be aware of that because DNS reply is not
kept with the provisioning from which the answer comes. The kept with the provisioning from which the answer comes. The
situation may become worse if asking internal name with public situation may become worse if asking internal name with public
address response or asking public name with private address address response or asking public name with private address
answers. answers.
skipping to change at page 8, line 47 skipping to change at page 9, line 9
the record is valid. That may cause messy for data connections, the record is valid. That may cause messy for data connections,
since NXDOMAIN doesn't provide useful information. since NXDOMAIN doesn't provide useful information.
By doing HE-MIF, it can help to solve the issues of DNS interception 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 captive portal. The DNS server modified and replied the answer
with the IP address of captive portal rather than the intended with the IP address of captive portal rather than the intended
destination address. In those cases, TCP connection may succeed, but destination address. In those cases, TCP connection may succeed, but
Internet connectivity is not available. It results in lack of Internet connectivity is not available. It results in lack of
service unless user has authenticated. HE-MIF recommended using service unless user has authenticated. HE-MIF recommended using
network connectivity status probes to examine a pre-configured URL network connectivity status probes to examine a pre-configured URL
for detecting DNS interception on the path (see more in Section 4.2). for detecting DNS interception on the path (see more in Section 5.2).
The node will be able to automatically rely upon other interfaces to The node will be able to automatically rely upon other interfaces to
select right DNS servers by excluding the unexamined interfaces. select right DNS servers by excluding the unexamined interfaces.
6.4. Flow Continuity 7.4. Flow Continuity
Interface changing should only happen at the beginning of new session [I-D.deng-mif-api-session-continuity-guide] describes session
in order to keep flow continuity for ongoing TCP session. Dynamic continuity guidance for application developers. The flow continuity
movement of traffic flows are beyond the scope of this document. topic is beyond this document scope.
7. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 9. Security Considerations
The security consideration is following the statement in [RFC6555]and The security consideration is following the statement in [RFC6555]and
[RFC6418]. [RFC6418].
9. Acknowledgements 10. Acknowledgements
The authors would like to thank Margaret Wasserman, Hui Deng, Erik The authors would like to thank Margaret Wasserman, Hui Deng, Erik
Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon
Perreault, Zhen Cao, Dmitry Anipko and Ted Lemon for their helpful Perreault, Zhen Cao, Dmitry Anipko, Ted Lemon, Daniel Migault, Russ
comments. White and Bing Liu for their helpful comments.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <http://www.rfc-editor.org/info/rfc4191>. November 2005, <http://www.rfc-editor.org/info/rfc4191>.
skipping to change at page 10, line 5 skipping to change at page 10, line 15
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>. <http://www.rfc-editor.org/info/rfc6724>.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
Recursive DNS Server Selection for Multi-Interfaced Recursive DNS Server Selection for Multi-Interfaced
Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,
<http://www.rfc-editor.org/info/rfc6731>. <http://www.rfc-editor.org/info/rfc6731>.
10.2. Informative References 11.2. Informative References
[I-D.deng-mif-api-session-continuity-guide]
Deng, H., Krishnan, S., Lemon, T., and M. Wasserman,
"Guide for application developers on session continuity by
using MIF API", draft-deng-mif-api-session-continuity-
guide-04 (work in progress), July 2014.
[I-D.ietf-mif-api-extension] [I-D.ietf-mif-api-extension]
Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API
consideration", draft-ietf-mif-api-extension-05 (work in consideration", draft-ietf-mif-api-extension-05 (work in
progress), February 2014. progress), February 2014.
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
DOI 10.17487/RFC5461, February 2009, DOI 10.17487/RFC5461, February 2009,
<http://www.rfc-editor.org/info/rfc5461>. <http://www.rfc-editor.org/info/rfc5461>.
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
Transition in the Session Initiation Protocol (SIP)",
RFC 6157, DOI 10.17487/RFC6157, April 2011,
<http://www.rfc-editor.org/info/rfc6157>.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418, Provisioning Domains Problem Statement", RFC 6418,
DOI 10.17487/RFC6418, November 2011, DOI 10.17487/RFC6418, November 2011,
<http://www.rfc-editor.org/info/rfc6418>. <http://www.rfc-editor.org/info/rfc6418>.
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for
Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419,
November 2011, <http://www.rfc-editor.org/info/rfc6419>.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<http://www.rfc-editor.org/info/rfc7556>. <http://www.rfc-editor.org/info/rfc7556>.
Authors' Addresses Authors' Addresses
Gang Chen Gang Chen
China Mobile China Mobile
29, Jinrong Avenue 29, Jinrong Avenue
Xicheng District, Xicheng District,
Beijing 100033 Beijing 100033
China China
Email: phdgang@gmail.com, chengang@chinamobile.com Email: phdgang@gmail.com, chengang@chinamobile.com
Carl Williams Carl Williams
 End of changes. 64 change blocks. 
194 lines changed or deleted 210 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/