Internet DRAFT - draft-baker-happier-eyeballs

draft-baker-happier-eyeballs






Network Working Group                                           F. Baker
Internet-Draft                                             Cisco Systems
Intended status: Informational                          November 5, 2012
Expires: May 9, 2013


                            Happier Eyeballs
                    draft-baker-happier-eyeballs-00

Abstract

   Multihoming in modern networks has problems with differing quality of
   routes.  This note generalizes the concept of happy eyeballs across a
   variety of multihoming scenarios.

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 May 9, 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
   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.





Baker                      Expires May 9, 2013                  [Page 1]

Internet-Draft      Generalized multihomed connection      November 2012


Table of Contents

   1.  Introduction: define "Multihoming"?  . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Generalizing RFC 6555  . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Implications of multihoming  . . . . . . . . . . . . . . .  4
     2.2.  The implications of multihoming for applications . . . . .  5
     2.3.  The implications of multihoming for operating systems  . .  6
   3.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  Privacy Considerations . . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10

































Baker                      Expires May 9, 2013                  [Page 2]

Internet-Draft      Generalized multihomed connection      November 2012


1.  Introduction: define "Multihoming"?

   In the Internet, we have a variety of definitions and implementations
   of multi-homing.

   The concept first comes up in [RFC0760], which states that "A host
   should also be able to have several physical interfaces (multi-
   homing)."  [RFC0799] restates this in another way, which the author
   likely thought of as equivalent but given history is tantalizing:
   "Furthermore, hosts can be multi-homed, that is, respond to more than
   one address."  [RFC0830] goes on to discuss a given host (as shown in
   its name record) being multihomed via more than one network, and
   [RFC0917] refers to routers as a class as "Internet hosts that are
   multi-homed and thus can serve as gateway."  These cases all refer to
   an individual system as being multihomed, defining the term as
   implying a multiplicity of addresses or interfaces that the host
   might use.

   The IP Version 6 Addressing Architecture [RFC4291] goes on to assert
   that "A single interface may also have multiple IPv6 addresses of any
   type (unicast, anycast, and multicast) or scope", which is to say
   that a particular model which is possible but unusual in IPv4 (that a
   given interface might have more than one address) is possible and
   normal in IPv6 - and as a result any IPv6 interface, by [RFC0799]'s
   logic, may itself be multihomed.

   [RFC1164] introduces the concept of a network being multihomed.  This
   is not absolutely new; if [RFC0830]'s host is attached to and derives
   addresses from multiple networks, it is a short step to assert that a
   network containing it is multihomed.  However, it sets forth four
   definitions that have proven seminal in operational deployment:

   "Autonomous System" or "AS"  a set of routers under a single
      technical administration, interconnected to other networks using
      an exterior gateway protocol (in this case BGP), that appears to
      other ASs to have a single coherent interior routing plan, and
      presents a consistent picture of what networks are reachable
      through it. [author's restatement of a larger paragraph]

   Stub AS:  an AS that has only a single connection to another AS.
      Naturally, a stub AS only carries local traffic.

   Multihomed AS:  an AS that has more than one connection to other ASs,
      but refuses to carry transit traffic.







Baker                      Expires May 9, 2013                  [Page 3]

Internet-Draft      Generalized multihomed connection      November 2012


   Transit AS:  an AS that has more than one connection to other ASs and
      is designed (under certain policy restrictions) to carry both
      transit and local traffic.

   [RFC6555] goes on to describe a scenario in which a host has multiple
   addresses and is therefore, by [RFC0799]'s logic, multihomed - but
   with a wrinkle.  In this case, some of the addresses might be IPv4
   [RFC0791] addresses, and some might be IPv6 [RFC2460] addresses, and
   they might be on the same or different interfaces.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Generalizing RFC 6555

   [RFC6555] makes it fairly clear that the applications it is thinking
   of are wide-ranging, referring to "(e.g., web browsers, email
   clients, instant messaging clients)".  However, its examples and text
   mostly refer to web browsers, which in turn run on TCP.  As a result,
   some commentators have inferred that it only deals with web browsers
   or only with TCP, and have gone on to repeat the specification for
   other applications.  This was not the intention of the authors, and
   is unfortunate.  But the specification does concern itself primarily
   with Dual Stack networks and hosts and applications in them.  The
   best application is wider yet.  This is to multihoming in all of its
   forms.

2.1.  Implications of multihoming

   A key implication of multihoming, regardless of the type of
   multihoming in view, is that there is potentially more than one route
   between two interfaces or systems, and the routes may have differing
   characteristics.  If a host has multiple interfaces, they are often
   of differing technology, such as Ethernet and WiFi or WiFi and LTE,
   and those interfaces may have differences in delay, capacity, loss
   rate, monetary cost, or routing policy.  Multihomed addressing
   implies multiple routes between systems, even if only in the first or
   final hop.  In addition, routing information or policy may come into
   play;

   o  [RFC6724] wonders whether any form of network address translation
      is in use,





Baker                      Expires May 9, 2013                  [Page 4]

Internet-Draft      Generalized multihomed connection      November 2012


   o  ULAs [RFC4193] may be preferred within a domain but not advertised
      between domains,

   o  a network may be using a prefix or address family internally but
      not externally,

   o  a filter may be in place in a firewall, or

   o  a normally-available route may be in flux or temporarily
      inoperative.

   In the extreme, routing may offer multiple paths between two AS's,
   and the differences among them may be satellite vs. terrestrial
   paths, which differ markedly in end-to-end delay, or between fiber
   and microwave, which can differ markedly in loss rate.

   In short, a {source, destination} address pair implies a route
   between those addresses, and multiple address pairs may imply
   multiple routes with different characteristics.

2.2.  The implications of multihoming for applications

   As such, the implication of multihoming for applications is that any
   application that finds itself on a multihomed host or attempting to
   open a session with a multihomed host - a host that has more than one
   address regardless of address family or underlying hardware - SHOULD
   be prepared to use any or all of them at any time, and SHOULD
   organize its algorithms to find one among them that provides adequate
   service with the least effort on its own part and impact on its user.
   If the application operates without user intervention or awareness,
   such as SMTP between MTAs, the decision should be transparent and
   immaterial to any user; one among the better routes should be chosen,
   and a user should not perceive non-intrinsic variability among them.
   If the application operates with user involvement, such as voice or
   video on RTP, web browser access, or electronic mail, the decision
   should be performed in a manner that minimizes user impact, including
   connection setup delays.

   An implementation MAY prefer IPv6 routes over IPv4 routes, such as by
   trying IPv6 addresses first.  If the difference is known, an
   application is well-advised to prefer native routes over translated
   routes, as is suggested in [RFC6724], for reasons such as those
   mentioned in [RFC2993].

   When comparing operational characteristics such as route quality, it
   is difficult to make a single recommendation for all applications, as
   applications may have differing requirements.  [RFC6555] suggests
   initiating a set of connection attempts at some cadence, and



Baker                      Expires May 9, 2013                  [Page 5]

Internet-Draft      Generalized multihomed connection      November 2012


   accepting the first to succeed, which at least obtains a route that
   provably works and may have a lower round-trip-time than other
   choices.

   If the implementation caches session metadata across multiple
   sessions, it may be useful to include and consider information such
   as

   o  Some sense of the success rate in connecting to a given address or
      prefix, such as succeeding in N out of M attempts.  M=0 implies
      that the address or prefix has not been tested.

   o  The round trip time on successful connection set-up, allowing the
      implementation to try lower-RTT routes first.

   o  If the connection moved at least a stated among of data to or from
      the peer, the effective throughput achieved, enabling an
      implementation to select high throughput routes first.  Short
      exchanges that do not achieve sustained throughput are likely to
      produce unreasonable numbers, and should therefore not be included
      in such a cache.

      In TCP terms, TCP's estimate of its throughput rate is the final
      value of cwnd*pmtu/mean_rtt times a scaling constant.

2.3.  The implications of multihoming for operating systems

   An unfortunate characteristic of the current Socket API
   [RFC3493][RFC5014] is that it forces the application to have
   knowledge of the IPv4 or IPv6 address of its peer and potentially of
   itself.  While there are cases in which it is useful to know that
   address, such as for logging, it is seldom required or useful once
   the session has been established.  A side-effect of having the
   application store the address as a result of one call and then use it
   in another is that the process of updating systems to use IPv6 forces
   a change to every implicated application.  As a result, we find
   operating systems deploying technologies such as Bump-in-the-Host
   [RFC6535] APIs, which translate IPv4 system calls into IPv6 behavior
   without informing the application.  Many of the issues encountered in
   renumbering [RFC4192] also derive from application shortcuts such as
   directly referring to addresses rather than names, or not updating
   cached information when it expires.

   It would be better if the socket "connect" API accepted a character
   string, which might contain a DNS name, an IPv4 address literal, or
   an IPv6 address literal, negotiated the connection in an [RFC6555]-
   compliant manner, and then returned either a connected socket or an
   error code, and additionally provided an API that enabled a



Baker                      Expires May 9, 2013                  [Page 6]

Internet-Draft      Generalized multihomed connection      November 2012


   application to obtain its peer's address from a connected socket,
   ideally as a character string.  In this way, the application using a
   network can be independent of the network, and insulated from changes
   to the network layer.

   Ideally, the API also enables the specification of the transport
   protocol or at least the type of service it seeks.  It might enable
   an octet stream interface using TCP [RFC0793], or a dynamic set of
   message stream interfaces associated with one peer using SCTP
   [RFC4960][RFC5061].  On a "listener" interface, the Socket API should
   be able to do the counterpart, permitting This has two values; the
   socket interface it replaces permits specification of the underlying
   transport, and support for more modern transports enables their
   convenient use.  This would be useful, for example, in obviating the
   issues of head-of-line blocking among exchanges in a pipelined TCP,
   obtaining web objects or performing Map/Reduce message exchanges in
   parallel instead.

   Creation of such an API in the ANSI standard would allow the Socket
   API to remove gethostbyname(), with its IPv4-only limitation, and
   getaddrinfo(), whose use results in the issue [RFC6555] addresses.

   One example of such an API, which unfortunately always uses TCP, is
   the java.net.Socket class

      public Socket(String host, int port) throws IOException
      public InetAddress getInetAddress()
      public InetAddress getLocalAddress()
      public int getPort()
      public int getLocalPort()

   The Windows WSAConnectByName and StreamSocket.ConnectAsync APIs, and
   the MacOSX CFStreamCreatePairWithSocketToHost API, are also examples
   of such an API, with the same limitation regarding the transport
   service.


3.  Conclusions

   In summary, although [RFC6555]'s examples are largely drawn from TCP
   and web service, is best understood as generalizing to all
   applications and transports.  It comments on session initiation in
   what this note points out are essentially multihomed environments.
   Whenever there exist a multiplicity of possible routes, selectable by
   the session originator through its choice of {source, destination}
   address pair, the application is best served by finding a useful
   route, or set of routes, quickly.  It SHOULD do so.




Baker                      Expires May 9, 2013                  [Page 7]

Internet-Draft      Generalized multihomed connection      November 2012


4.  IANA Considerations

   This memo asks the IANA for no new parameters.


5.  Security Considerations

   This note makes no observations regarding security, and does not
   impact it.


6.  Privacy Considerations

   This note makes no observations regarding privacy, and does not
   impact it.


7.  Acknowledgements

   The author received comments from Dan Wing, Dave Thaler, Erik
   Nordmark, Mark Townsley, Ralph Droms, and Stuart Cheshire.


8.  Change Log

   Initial Version:  November 2012


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, April 2012.

9.2.  Informative References

   [RFC0760]  Postel, J., "DoD standard Internet Protocol", RFC 760,
              January 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.



Baker                      Expires May 9, 2013                  [Page 8]

Internet-Draft      Generalized multihomed connection      November 2012


   [RFC0799]  Mills, D., "Internet name domains", RFC 799,
              September 1981.

   [RFC0830]  Su, Z., "Distributed system for Internet name service",
              RFC 830, October 1982.

   [RFC0917]  Mogul, J., "Internet subnets", RFC 917, October 1984.

   [RFC1164]  Honig, J., Katz, D., Mathis, M., Rekhter, Y., and J. Yu,
              "Application of the Border Gateway Protocol in the
              Internet", RFC 1164, June 1990.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
              November 2000.

   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
              Stevens, "Basic Socket Interface Extensions for IPv6",
              RFC 3493, February 2003.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5014]  Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
              Socket API for Source Address Selection", RFC 5014,
              September 2007.

   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
              Kozuka, "Stream Control Transmission Protocol (SCTP)
              Dynamic Address Reconfiguration", RFC 5061,
              September 2007.

   [RFC6535]  Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
              Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,



Baker                      Expires May 9, 2013                  [Page 9]

Internet-Draft      Generalized multihomed connection      November 2012


              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.


Author's Address

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com







































Baker                      Expires May 9, 2013                 [Page 10]