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

Versions: 00 01 02 03 04 draft-ietf-mif-happy-eyeballs-extension

Internet Engineering Task Force                                  G. Chen
Internet-Draft                                              China Mobile
Intended status: Informational                               C. Williams
Expires: September 13, 2012                                   Consultant
                                                                 D. Wing
                                                          A. Yourtchenko
                                                     Cisco Systems, Inc.
                                                          March 12, 2012


            Happy Eyeballs Extension for Multiple Interfaces
               draft-chen-mif-happy-eyeballs-extension-04

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 September 13, 2012.

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



Chen, et al.           Expires September 13, 2012               [Page 1]

Internet-Draft          happy-eyeballs-extension              March 2012


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Heuristic Happy Eyeballs Extension Algorithm  . . . . . . . . . 3
     2.1.  The Framework for Extended Algorithm  . . . . . . . . . . . 3
     2.2.  Happiness Parameters  . . . . . . . . . . . . . . . . . . . 4
     2.3.  Requirements for Implementations  . . . . . . . . . . . . . 5
     2.4.  MIF HE Data Processing  . . . . . . . . . . . . . . . . . . 5
     2.5.  IPv4/IPv6 Selection Algorithm for Individual Interface  . . 6
   3.  Additional Considerations . . . . . . . . . . . . . . . . . . . 6
     3.1.  Usage Scope . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.2.  Flow Continuity . . . . . . . . . . . . . . . . . . . . . . 6
     3.3.  Default Address Selection . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7


























Chen, et al.           Expires September 13, 2012               [Page 2]

Internet-Draft          happy-eyeballs-extension              March 2012


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

                       MIF Happy Eyeballs Framework

   Therein, several "Happiness" parameters have been defined and feeded



Chen, et al.           Expires September 13, 2012               [Page 3]

Internet-Draft          happy-eyeballs-extension              March 2012


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

      *  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
         requested name should also be increased.




Chen, et al.           Expires September 13, 2012               [Page 4]

Internet-Draft          happy-eyeballs-extension              March 2012


      *  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.  Requirements for Implementations

   The implementations of MIF HE modules should have a good transparency
   for applications and system kernel .  The modules is responsible for
   two functionalities, i.e.  HE syntax resolving and HE connection
   initiation .  HE syntax resolving is capable of analyzing application
   demands and mapping to H.E. parameters.  Resolved parameter may
   include "Hard" or "Soft" preconditions which are indicated in section
   2.2.  Afterwards, "Filter" and "Sort" are rules applied to make a
   step-wise processing .  Depending on the judgement, the modules would
   initiate the connection to system kernel and choose a proper
   interface.

2.4.  MIF 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



Chen, et al.           Expires September 13, 2012               [Page 5]

Internet-Draft          happy-eyeballs-extension              March 2012


   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.

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




Chen, et al.           Expires September 13, 2012               [Page 6]

Internet-Draft          happy-eyeballs-extension              March 2012


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-04
              (work in progress), February 2012.

   [I-D.ietf-mif-dns-server-selection]
              Kato, J., Lemon, T., and T. Savolainen, "Improved DNS
              Server Selection for Multi-Interfaced Nodes",
              draft-ietf-mif-dns-server-selection-07 (work in progress),
              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-07
              (work in progress), December 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: phdgang@gmail.com


   Carl Williams
   Consultant
   El Camino Real
   Palo Alto, CA  94306
   USA

   Email: carlw@mcsr-labs.org




Chen, et al.           Expires September 13, 2012               [Page 7]

Internet-Draft          happy-eyeballs-extension              March 2012


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

   Email: dwing@cisco.com


   Andrew Yourtchenko
   Cisco Systems, Inc.
   El Camino Real
   De Kleetlaan, 7  Diegem B-1831
   Belgium

   Email: ayourtch@cisco.com



































Chen, et al.           Expires September 13, 2012               [Page 8]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/