One document matched: draft-baker-happier-eyeballs-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-happier-eyeballs-00"
ipr="trust200902">
<front>
<title abbrev="Generalized multihomed connection">Happier Eyeballs</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2012" />
<area>Internet</area>
<workgroup></workgroup>
<abstract>
<t>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.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction: define "Multihoming"?">
<t>In the Internet, we have a variety of definitions and implementations
of multi-homing.</t>
<t>The concept first comes up in <xref target="RFC0760"></xref>, which
states that "A host should also be able to have several physical
interfaces (multi-homing)." <xref target="RFC0799"></xref> 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." <xref
target="RFC0830"></xref> goes on to discuss a given host (as shown in
its name record) being multihomed via more than one network, and <xref
target="RFC0917"></xref> 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.</t>
<t>The <xref target="RFC4291">IP Version 6 Addressing
Architecture</xref> 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 <xref target="RFC0799"></xref>'s logic, may itself be
multihomed.</t>
<t><xref target="RFC1164"></xref> introduces the concept of a network
being multihomed. This is not absolutely new; if <xref
target="RFC0830"></xref>'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: <list
style="hanging">
<t hangText=""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]</t>
<t hangText="Stub AS:">an AS that has only a single connection to
another AS. Naturally, a stub AS only carries local traffic.</t>
<t hangText="Multihomed AS:">an AS that has more than one connection
to other ASs, but refuses to carry transit traffic.</t>
<t hangText="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.</t>
</list></t>
<t><xref target="RFC6555"></xref> goes on to describe a scenario in
which a host has multiple addresses and is therefore, by <xref
target="RFC0799"></xref>'s logic, multihomed - but with a wrinkle. In
this case, some of the addresses might be <xref
target="RFC0791">IPv4</xref> addresses, and some might be <xref
target="RFC2460">IPv6</xref> addresses, and they might be on the same or
different interfaces.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section anchor="rfc6555" title="Generalizing RFC 6555">
<t><xref target="RFC6555"></xref> 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.</t>
<section title="Implications of multihoming">
<t>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;
<list style="symbols">
<t><xref target="RFC6724"></xref> wonders whether any form of
network address translation is in use,</t>
<t><xref target="RFC4193">ULAs</xref> may be preferred within a
domain but not advertised between domains,</t>
<t>a network may be using a prefix or address family internally
but not externally,</t>
<t>a filter may be in place in a firewall, or</t>
<t>a normally-available route may be in flux or temporarily
inoperative.</t>
</list></t>
<t>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.</t>
<t>In short, a {source, destination} address pair implies a route
between those addresses, and multiple address pairs may imply multiple
routes with different characteristics.</t>
</section>
<section title="The implications of multihoming for applications">
<t>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.</t>
<t>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 <xref target="RFC6724"></xref>, for reasons
such as those mentioned in <xref target="RFC2993"></xref>.</t>
<t>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. <xref
target="RFC6555"></xref> suggests initiating a set of connection
attempts at some cadence, and 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.</t>
<t>If the implementation caches session metadata across multiple
sessions, it may be useful to include and consider information such as
<list style="symbols">
<t>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.</t>
<t>The round trip time on successful connection set-up, allowing
the implementation to try lower-RTT routes first.</t>
<t>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. <vspace blankLines="1" /> In TCP terms, TCP's
estimate of its throughput rate is the final value of
cwnd*pmtu/mean_rtt times a scaling constant.</t>
</list></t>
</section>
<section title="The implications of multihoming for operating systems">
<t>An unfortunate characteristic of the current <xref
target="RFC3493">Socket API</xref><xref target="RFC5014"></xref> 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
<xref target="RFC6535">Bump-in-the-Host</xref> APIs, which translate
IPv4 system calls into IPv6 behavior without informing the
application. Many of the issues encountered in <xref
target="RFC4192">renumbering</xref> also derive from application
shortcuts such as directly referring to addresses rather than names,
or not updating cached information when it expires.</t>
<t>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 <xref
target="RFC6555"></xref>-compliant manner, and then returned either a
connected socket or an error code, and additionally provided an API
that enabled a 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.</t>
<t>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 <xref target="RFC0793">TCP</xref>, or a
dynamic set of message stream interfaces associated with one peer
using <xref target="RFC4960">SCTP</xref><xref
target="RFC5061"></xref>. 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.</t>
<t>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 <xref
target="RFC6555"></xref> addresses.</t>
<t>One example of such an API, which unfortunately always uses TCP, is
the java.net.Socket class<list style="empty">
<t>public Socket(String host, int port) throws
IOException<vspace /> public InetAddress
getInetAddress()<vspace /> public InetAddress
getLocalAddress()<vspace /> public int getPort()<vspace /> public
int getLocalPort()</t>
</list></t>
<t>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.</t>
</section>
</section>
<section title="Conclusions">
<t>In summary, although <xref target="RFC6555"></xref>'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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This note makes no observations regarding security, and does not
impact it.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>This note makes no observations regarding privacy, and does not
impact it.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The author received comments from Dan Wing, Dave Thaler, Erik
Nordmark, Mark Townsley, Ralph Droms, and Stuart Cheshire.</t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">November 2012</t>
</list></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.6555" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0760" ?>
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.0799" ?>
<?rfc include="reference.RFC.0830" ?>
<?rfc include="reference.RFC.0917" ?>
<?rfc include="reference.RFC.1164" ?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.2993"?>
<?rfc include="reference.RFC.3493" ?>
<?rfc include="reference.RFC.4192" ?>
<?rfc include="reference.RFC.4193" ?>
<?rfc include="reference.RFC.4291" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.5014" ?>
<?rfc include="reference.RFC.5061" ?>
<?rfc include="reference.RFC.6535" ?>
<?rfc include="reference.RFC.6724" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:44:12 |