[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-chen-mif-happy-eyeballs-extension) 00 01 02 03 04 05 06 07 08 09 10 11

Internet Engineering Task Force                                  G. Chen
Internet-Draft                                              China Mobile
Intended status: Informational                               C. Williams
Expires: August 24, 2016                                      Consultant
                                                                 D. Wing
                                                          A. Yourtchenko
                                                     Cisco Systems, Inc.
                                                       February 21, 2016

            Happy Eyeballs Extension for Multiple Interfaces


   This memo proposes extensions to the Happy Eyeball(HE) defined in
   RFC6555 and fit into a multiple provisioning domain architecture.
   Happy Eyeballs in MIF would make the selection process smoother by
   using connectivity tests over pre-filtered interfaces according to
   defined policy.  This would choose the most fast interface with an
   automatic fallback mechnism.

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 August 24, 2016.

Copyright Notice

   Copyright (c) 2016 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 August 24, 2016                [Page 1]

Internet-Draft             happy-eyeballs-mif              February 2016

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Happiness Parameters  . . . . . . . . . . . . . . . . . . . .   4
   5.  HE-MIF behavior . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  First Step, Filter  . . . . . . . . . . . . . . . . . . .   5
     5.2.  Second Step, Sort . . . . . . . . . . . . . . . . . . . .   6
   6.  Implementation Framework  . . . . . . . . . . . . . . . . . .   7
   7.  Additional Considerations . . . . . . . . . . . . . . . . . .   7
     7.1.  Usage Scope . . . . . . . . . . . . . . . . . . . . . . .   7
     7.2.  Fallback Timeout  . . . . . . . . . . . . . . . . . . . .   7
     7.3.  DNS Selections  . . . . . . . . . . . . . . . . . . . . .   8
     7.4.  Flow Continuity . . . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   In a multiple interface context, the problems raised by hosts with
   multiple interfaces have been discussed in the MIF problem statement
   [RFC6418], which describes the various issues when using a wrong
   domain selection on a MIF node.  Happy Eyeballs (HE) [RFC6555]
   describes how a dual-stack client can determine the most fast path to
   a dual-stack server by employing a stateful algorithm to quickly
   discover if the IPv4 or IPv6 path is faster.  while this is a good
   method to achieve smart path selection, it assumes a single-homed
   node targeted.  Interaction with multiple interfaces was deferred for
   further study.

   [RFC7556] has proposed a multiple provisioning domain architecture.
   This memo proposes extensions to the Happy Eyeball(HE) defined in
   [RFC6555] to support multiple interfaces, such that a node with
   multiple interfaces can choose the most fast path for a particular
   connection-oriented flow (e.g., TCP, SCTP).

Chen, et al.             Expires August 24, 2016                [Page 2]

Internet-Draft             happy-eyeballs-mif              February 2016

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

   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.

   Use Case: WiFi is broken

   Assuming a MIF node has both 3GPP mobile network interface and WiFi
   interface, a common practice would always prefer WiFi connection when
   the node enters a WiFi area.  In this situation, a node might assume
   the WiFi link can reach destinations on the global Internet, because
   a valid IP address has been assigned on the interface.  However, this
   might not be the case for several reasons, such as authentication
   requirements, instability at layer 2, or even, perhaps, the WiFi
   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
   to wait an appropriate time slot but not forever.  After the timer is
   expired, users may finally give up the WiFi path and try to establish
   connection over a 3GPP mobile network path.  Users may not want a
   very short timer, because the mobile network path for most people is
   more expensive than a WiFi path.  An appropriate timer is desired to
   balance user experience and expenditure.

   Use Case: Policy Conflict

   A node has both WiFi and 3GPP network access simultaneously.  In a
   mobile network, IPv6-only may be preferable since IPv6 has the
   potential to be simpler than dual-stack.  WiFi access still remains
   on IPv4.  The problem is caused by source address selection principle
   [RFC6724] and wifi preference.  The transition to IPv6 is likely to
   encourage and prefer IPv6 . If a 3GPP network path has IPv6 on it and
   a WiFi does not, the 3GPP interface might be chosen while it maybe a
   suboptimal selection since the wifi interface likely is less
   expensive.  With HE-MIF, user's interests could be well understood

Chen, et al.             Expires August 24, 2016                [Page 3]

Internet-Draft             happy-eyeballs-mif              February 2016

   and considered before interface selection.  Different preconditions
   can impact subsequent behaviors.  Users concern about high-
   reliability or high-speed or less-cost would make different choicies.
   A flexible mechanism is provided to make smart decision.

4.  Happiness Parameters

   This section provides a design proposal for HE-MIF.  Two sets of
   "Happiness" parameters have been defined.  It serves applications and
   initiates HE-MIF connections tests subsequently.  Going through the
   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: Contains parameters which must be complied with.  It
      helps to select candidate interfaces through which a particular
      flow should be directed.  These should be seen as constraints on
      the choice, such as provider policies, support for IPv4 or IPv6,
      and other parameters which would prevent a particular interface
      and transport from being used by a particular flow.  Parameters in
      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 may express preferences which likely
         not have a formally technical language , like "No 3G while
         roaming", "Only use free WiFi", etc.

      *  Operator policy: operators may deliver the customized policies
         in a particular network environment because of 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).

   o  Soft Set: Contains factors which impact the selection of the path
      across which a particular flow should be transmitted among the
      available interfaces and transports which meet the hard set
      requirements described above.  Examples might include:

      *  PVD-ID (Provisioning Domain Identity): PVD-aware node may
         decide to use one preferred PVD or allow use multiple PVDs
         simultaneously for applications.  The node behavior should be
         consistent with MPVD architecture [RFC7556].

      *  Next hop: [RFC4191] allows configuration of specific routes to
         a destination.

Chen, et al.             Expires August 24, 2016                [Page 4]

Internet-Draft             happy-eyeballs-mif              February 2016

      *  DNS selection: [RFC6731] could configure nodes with information
         to indicate a DNS server address for a particular namespace.

      *  Source address selection: the information provided by [RFC6724]
         should 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.

5.  HE-MIF behavior

   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
   policies from different actors (e.g., users and network operator).
   In a nutshell, that is a filter which will exclude the interfaces
   from any further consideration.  The second is to adjust how a node
   make a connection on multiple interfaces after the filter.  It's
   sorting behavior.  In the multiple provisioning domain architecture,
   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
   Set to proceed the sort process.

   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 very specific to particular cases and implementations.  For
   example, if only one interface is left after the first step, the
   process is likely ceased.

5.1.  First Step, Filter

   One goal of the filter is to reconcile multiple selection policies
   from users or operators.  Afterwards, 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 because of cost
   saving consideration.  Whereas, users may dedicatedly prefer a 3GPP
   network interface to seek high-reliability or security benefits even
   to manually turn off WiFi interface.  The decision on mergence of
   policies may be made by implementations, by node administrators, even
   by other standards investigating customer behavior.  However, it's
   worth to note that a demand from users should be normally considered
   higher priority than from other actors.

Chen, et al.             Expires August 24, 2016                [Page 5]

Internet-Draft             happy-eyeballs-mif              February 2016

   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 the next step.

5.2.  Second Step, Sort

   A Sort process guarantees a fast interface selection with fallback
   capacities.  As stated in [RFC7556], a PVD-aware node shall perform
   connectivity test and, only after validation of the PVD, consider
   using it to serve application connections requests.  In current
   implementations, some nodes already implement this, e.g., by trying
   to reach a dedicated web server (see [RFC6419] ).  If anything is
   abnormal, it assumes there is a proxy on the path.  This status
   detection is recommended to be used in HE-MIF to detect DNS
   interception or HTTP proxy that forces a login or a click-through.
   Unexamined PVDs or interfaces should be accounted as "unconnected".
   It should not join the sort process.

   Afterwards, two phases normally are involved in a Sort process, i.e.,
   name resolving and connection establishment.  The Soft set parameters
   defined in Section 4 should considered at this stage.

   When a node initiates name resolution requests, it should check if
   there is a matched PVD ID for the destination name.  A PVD agnostic
   node may request DNS server selection DHCP option [RFC6731] for
   interface selection guidance.  Those information may weight a
   particular interface to be preferred to others sending resolving
   requests.  If the node can't find useful information in the Soft Set,
   DNS queries would be sent out on multiple interfaces in parallel to
   maximize chances for connectivity.  Some additional discussions of
   DNS selection consideration of HE-MIF are described in Section 7.3.

   Once a destination address was resolved, a connection is to be setup.
   For the given destination address, a PVD-aware node selects a next-
   hop and source address associated with that PVD in the name
   resolution process.  A PVD agnostic node may receive certain next hop
   in a RA message [RFC4191], the node selects best source address
   according to the rules [RFC6724].  When destination and source pairs
   are identified, it should be treated with higher priority compared to
   others and choose to initiate the connection in advance.  This could
   avoid thrashing the network, by not making simultaneous connection
   attempts on multiple interfaces.  After making a connection attempt
   on the preferred pairs and failing to establish a connection within a
   certain time period (see Section 7.2), a HE-MIF implementation will
   decide to initiate connection attempt using rest of interfaces in
   parallel.  This fallback consideration will make subsequent
   connection attempts successful on non-preferable interfaces.

Chen, et al.             Expires August 24, 2016                [Page 6]

Internet-Draft             happy-eyeballs-mif              February 2016

   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 family states.

   If there are no specific Soft Set provided, all selected interfaces
   should be equally treated.  The connections would initiate on several
   interface simultaneously.  The goal here is to provide the most fast
   connection for users, by quickly attempting to connect using each
   candidate interface.  Afterwards, the node would do the same caching
   and flushing process as described above.

6.  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

7.  Additional Considerations

7.1.  Usage Scope

   Connection-oriented transports (e.g., TCP, SCTP) are directly applied
   as scoped in [RFC6555].  For connectionless transport protocols
   (e.g., UDP), a similar mechanism can be used if the application has
   request/response semantics.  Further investigrations are out of the
   document scope.

7.2.  Fallback Timeout

   When the preferred interface was failed, HE-MIF would trigger a
   fallback process to start connection initiation on several candidate
   interfaces.  It should set a reasonable wait time to comfort user
   experience.  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 3GPP networks brings
   a charge to customers.  Considering the reasons, it is recommended to
   prioritize the input from users (e.g., real customers or
   applications) through user interface.  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

Chen, et al.             Expires August 24, 2016                [Page 7]

Internet-Draft             happy-eyeballs-mif              February 2016

   provide TCP retransmission.  However, several minutes delay may not
   inappropriate for user experiences.  A widespread practice [RFC5461]
   sets 75 seconds to optimize connection process.

   More optimal timer may be expected.  The particular setting will be
   very specific to implementations and cases.  The memo didn't try to
   provide a concrete value because of following concerns.

   o  RTT (Round-Trip Time) on different interfaces may vary quite a
      lot.  A particular value of timeout may not accurately help to
      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
      very fast.  In order to compensate the issues, the timeout setting
      based on past experiences of a particular interface may help to
      make a fair decision.  Whereas, it's going beyond the capability
      of Happy Eyeballs [RFC6555].  Therefore, it leaves a particular

   o  In some cases, fast interface may not be treated as "best".  For
      example, a interface could be evaluated in the principle of
      bandwidth-delay, termed "Bandwidth-Delay-Product ".  Happy
      Eyeballs measures only connection speed.  That is, how quickly a
      TCP connection is established . It does not measure bandwidth.  If
      the fallback has to take various factors into account and make
      balanced decision, it's better to resort to a specific context and

7.3.  DNS Selections

   In the Sort process, HE-MIF prioritizes PVD-ID match or [RFC6731]
   inputs to select a proper server.  It could help to address following
   two cases.

   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
      kept with the provisioning from which the answer comes.  The
      situation may become worse if asking internal name with public
      address response or asking public name with private address

   o  Some FQDNs can be resolvable only by sending queries to the right
      server (e.g., intranet services).  Otherwise, a response with
      NXDOMAIN is replied.  Fast response is treated as optimal only if
      the record is valid.  That may cause messy for data connections,
      since NXDOMAIN doesn't provide useful information.

   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

Chen, et al.             Expires August 24, 2016                [Page 8]

Internet-Draft             happy-eyeballs-mif              February 2016

   with the IP address of captive portal rather than the intended
   destination address.  In those cases, TCP connection may succeed, but
   Internet connectivity is not available.  It results in lack of
   service unless user has authenticated.  HE-MIF recommended using
   network connectivity status probes to examine a pre-configured URL
   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
   select right DNS servers by excluding the unexamined interfaces.

7.4.  Flow Continuity

   [I-D.deng-mif-api-session-continuity-guide] describes session
   continuity guidance for application developers.  The flow continuity
   topic is beyond this document scope.

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Security Considerations

   The security consideration is following the statement in [RFC6555]
   and [RFC6418].

10.  Acknowledgements

   The authors would like to thank Margaret Wasserman, Hui Deng, Erik
   Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon
   Perreault, Zhen Cao, Dmitry Anipko, Ted Lemon, Daniel Migault, Russ
   White and Bing Liu for their helpful comments.

11.  References

11.1.  Normative References

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
              November 2005, <http://www.rfc-editor.org/info/rfc4191>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
              2012, <http://www.rfc-editor.org/info/rfc6555>.

Chen, et al.             Expires August 24, 2016                [Page 9]

Internet-Draft             happy-eyeballs-mif              February 2016

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,

   [RFC6731]  Savolainen, T., Kato, J., and T. Lemon, "Improved
              Recursive DNS Server Selection for Multi-Interfaced
              Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,

11.2.  Informative References

              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.

              Liu, D., Lemon, T., Ismailov, Y., and Z. Cao, "MIF API
              consideration", draft-ietf-mif-api-extension-05 (work in
              progress), February 2014.

   [RFC5461]  Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
              DOI 10.17487/RFC5461, February 2009,

   [RFC6418]  Blanchet, M. and P. Seite, "Multiple Interfaces and
              Provisioning Domains Problem Statement", RFC 6418,
              DOI 10.17487/RFC6418, November 2011,

   [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
              Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,

Authors' Addresses

Chen, et al.             Expires August 24, 2016               [Page 10]

Internet-Draft             happy-eyeballs-mif              February 2016

   Gang Chen
   China Mobile
   29, Jinrong Avenue
   Xicheng District,
   Beijing  100033

   Email: phdgang@gmail.com, chengang@chinamobile.com

   Carl Williams
   El Camino Real
   Palo Alto, CA  94306

   Email: carlw@mcsr-labs.org

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134

   Email: dwing@cisco.com

   Andrew Yourtchenko
   Cisco Systems, Inc.
   De Kleetlaan, 7
   Diegem  B-1831

   Email: ayourtch@cisco.com

Chen, et al.             Expires August 24, 2016               [Page 11]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/