One document matched: draft-baker-bmwg-testing-eyeball-happiness-01.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="std" docName="draft-baker-bmwg-testing-eyeball-happiness-01"
ipr="trust200902">
<front>
<title abbrev="">Testing Eyeball Happiness</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="2010" />
<area>Operations and Management</area>
<workgroup>IPv6 Operations</workgroup>
<abstract>
<t>The amount of time it takes to open a session using common transport
APIs in dual stack networks and networks with filtering such as proposed
in BCP 38 is a barrier to IPv6 deployment. This note describes a test
that can be used to determine whether an application can reliably open
sessions quickly in a complex environment such as dual stack (IPv4+IPv6)
deployment or IPv6 deployment with multiple prefixes and upstream
ingress filtering. This test is not a test of a specific algorithm, but
of the external behavior of the system as a black box. Any algorithm
that has the intended external behavior will be accepted by it.</t>
</abstract>
<!-- <note title="Foreword"> </note>bmwg -->
<!--
<note title="Requirements"> <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> </note>
-->
<!--
<?rfc needLines="10" ?>
<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">
<t>The <xref target="I-D.wing-v6ops-happy-eyeballs-ipv6">Happy
Eyeballs</xref> specification observes on an issue in deployed
multi-prefix IPv6-only and dual stack networks, and proposes a
correction. <xref target="RFC5461"></xref> similarly looks at TCP's
response to so-called "soft errors" (ICMP host and network unreachable
messages), pointing out an issue and a set of solutions. In a network
that contains both <xref target="RFC0791">IPv4</xref> and <xref
target="RFC2460">IPv6</xref> prefixes and routes or that uses multiple
prefixes allocated by upstream providers that implement <xref
target="RFC2827">BCP 38 Ingress Filtering</xref>, the fact that two
hosts that need to communicate have addresses using the same
architecture does not imply that the network has usable routes
connecting them, or that those addresses are useful to the applications
in question. In addition, the process of opening a session using the
<xref target="RFC3493">Sockets API</xref> is generally described in
terms of obtaining a list of possible addresses for a peer (which will
normally include both IPv4 and IPv6 addresses) using getaddrinfo() and
trying them in sequence until one succeeds or all have failed. This
naive algorithm, if implemented as described, has the side-effect of
making the worst case delay in opening a session far longer than human
patience normally allows.</t>
<t>This note describes a test that can be used to determine whether an
application can reliably open sessions quickly in a complex environment
such as dual stack (IPv4+IPv6) deployment or IPv6 deployment with
multiple prefixes and upstream ingress filtering. This is not a test of
a specific algorithm, but a measurement of the external behavior of the
system as a black box. The question is how long it takes an application,
best case and worst case, to open a session with a server or peer.</t>
</section>
<section anchor="test" title="Measuring eyeball happiness">
<t>This measurement determines the amount of time it takes an
application to open a session with a peer in the presence of at least
one IPv4 and multiple IPv6 prefixes and a variety of network behaviors.
ISPs are reporting that a host (MacOSX, Windows, Linux, FreeBSD, etc)
that has more than one address (an IPv4 and an IPv6 address, two global
IPv6 addresses, etc) may serially try addresses, allowing each TCP setup
to expire, taking several seconds for each attempt. There have been
reports of a session setup taking as long as 40 seconds as a result. The
amount of time necessary to establish communication between two entities
should be approximately the same regardless of the type of address
chosen or the viability of routing in the specific network.</t>
<section anchor="testbed" title="Happy Eyeballs test bed configuration">
<t>The configuration of equipment and applications is as shown in
<xref target="test1"></xref>.</t>
<figure anchor="test1" title="Generic Test Environment">
<artwork align="center"><![CDATA[
+--------+ | |198.51.100.0/24
|Protocol| |192.0.2.0/24 |2001:DB8:0:2::/64
|Analyzer+-+2001:DB8:1:0::/64 |2001:DB8:1:4::/64
+--------+ |2001:DB8:0:1::/64 |2001:DB8:2:4::/64
| |
+-----+ | | +-----+
|Alice+-+ +-+ Bob |
+-----+ | +-------+ +-------+ | +-----+
+-+Router1| |Router2+-+
+-----+ | +-----+-+ +-+-----+ |
| DNS +-+ | | |
+-----+ | -+------+- |
| 203.0.113.0/24 |
| 2001:DB8:0:3::/64 |
]]></artwork>
</figure>
<t>Alice is the unit being measured, the computer running the process
that will open a session with Bob for the application in question. DNS
is represented in the diagram as a separate system, as is the protocol
analyzer that will watch Alice's traffic. This is not absolutely
necessary; If one computer can run tcpdump and a DNS server process -
and for that matter subsume the routers - that is acceptable. The
units are separated in the test for purposes of clarity.</t>
<t>On each test run, configuration is performed in Router 1 to permit
only one route to work. There are various ways this can be
accomplished, including but not limited to installing<list
style="symbols">
<t>a filter that drops datagrams to Bob resulting in an ICMP
"administratively prohibited",</t>
<t>a filter that drops datagrams to Bob silently,</t>
<t>a null route or removing the route to one of Bob's prefixes,
resulting in an ICMP "destination unreachable", and</t>
<t>a middleware program that responds with a TCP RST.</t>
</list></t>
<t>The tester should try different methods to determine whether
differences in this configuration make a difference in the test. For
example, one might find that the application under test responds
differently to a TCP RST than to a silent packet loss.</t>
</section>
<section anchor="procedure" title="Happy Eyeballs test procedure">
<t>Consider a network as described in <xref target="testbed"></xref>.
Alice and Bob each have a set of one or more IPv4 and two or more IPv6
addresses in DNS, and routers 1 and 2 are configured to route the
relevant prefixes. The measurement plays with an access list or null
route in Router 1 that would prevent traffic Alice->Bob using each
of Bob's addresses. If Bob has a total of N addresses, we run the
measurement at least N times, permitting exactly one of the addresses
to enjoy end to end communication each time. If the DNS service
randomizes the order of the addresses, this may not result in a test
requiring opening a connection to all of the addresses; in this case,
the test will have to be run repeatedly until in at least one instance
a TCP SYN or its equivalent is seen for each relevant address. The
tester should either flush the resolver cache between iterations, to
force repeated DNS resolution, or should wait for at least the DNS RR
TTL on each resource record. In the latter case, the tester should
also observe DNS re-resolving; if not, the application is not
correctly using DNS.</t>
<t>This specification assumes common LAN technology with no competing
traffic and nominal propagation delays, so that they are not a factor
in the measurement.</t>
<t>The objective is to measure the amount of time required to open a
session. This includes the time from Alice's initial DNS request
through one or more attempts to open a session to the session being
opened, as seen in the LAN trace. The simplest way to measure this
will be to put a traffic analyzer on Alice's point of attachment and
capture the messages exchanged by Alice.</t>
<figure anchor="tcpflow" title="Message flow using TCP">
<artwork align="center"><![CDATA[
DNS Server Alice Bob
| | |
1. |<--www.example.com A------| |
2. |<--www.example.com AAAA---| |
3. |---192.0.2.1------------->| |
4. |---2001:dba::1----------->| |
5. | | |
6. | |--TCP SYN, IPv6--->X |<***********
7. | |--TCP SYN, IPv6--->X | |
8. | |--TCP SYN, IPv6--->X | TCP 3wHS
9. | | | Time
10. | |--TCP SYN, IPv4------->|(any family)
11. | |<-TCP SYN+ACK, IPv4----| |
12. | |--TCP ACK, IPv4------->|<***********
]]></artwork>
</figure>
<t>In a TCP-based application (<xref target="tcpflow"></xref>), that
would be from the DNS request on line 1 through the first completion
of a TCP three-way handshake, the transmission on line 12.</t>
<figure anchor="udpflow" title="Message flow using UDP">
<artwork align="center"><![CDATA[
DNS Server Alice Bob
| | |
1. |<--www.example.com A------| |
2. |<--www.example.com AAAA---| |
3. |---192.0.2.1------------->| |
4. |---2001:dba::1----------->| |
5. | | |
6. | |--UDP Request, IPv6-->X|
7. | |--UDP Request, IPv6-->X|
8. | |--UDP Request, IPv6-->X|
9. | | |
10. | |--UDP Request, IPv4--->|
11. | |<-UDP Response, IPv4---|
]]></artwork>
</figure>
<t>In a UDP-based application (<xref target="udpflow"></xref>), that
would be from the DNS request (line 1) through one or more UDP
Requests (lines 6-10) until a UDP Response is seen (line 11).</t>
<t>When using other transports, the methodology will have to be
specified in context; it should measure the same event.</t>
</section>
<section anchor="metrics" title="Happy Eyeballs metrics">
<t>The measurements taken are the duration of the interval from the
initial DNS request until the session is seen to be open, as described
in <xref target="procedure"></xref>. We are interested in the shortest
and longest durations (which will most likely be those that send one
SYN and succeed and those that send a SYN to each possible address
before succeeding in one of the attempts), and the pattern of attempts
sent to different addresses. The pattern may be to simply send an
attempt every <time interval>, or may be more complex; as a
result, this is in part descriptive.</t>
<section anchor="Max-metric"
title="Metric: Maximum Session Setup Interval">
<t><list style="hanging">
<!-- The normative part of a metric definition MUST define at least the following: -->
<!-- Metric names MUST be unique within the set of metrics being defined and MAY be descriptive. -->
<t hangText="Name:">Maximum Session Setup Interval</t>
<!-- The description MUST explain what the metric is, what is being measured and how this relates to the performance of the system being measured. -->
<t hangText="Description:">The maximum session setup interval is
the longest period of time observed for the opening of a
session.</t>
<!-- This method of measurement or calculation MUST define what is being measured or computed and the specific algorithm to be used. Does the measurement involve active or only passive measurements? Terms such as "average" should be qualified (e.g. running average or average over some interval). ... Some parameters linked to the method MAY also be reported, in order to fully interpret the performance metric. For example, the time interval, the load, the minimum packet loss, etc... -->
<t hangText="Methodology:">In the LAN analyzer trace, note the
times of the initial DNS request and the confirmation that the
session is open as described in <xref
target="procedure"></xref>. Several instances of the test will
be run, in at least one of which an attempt is seen to each of
Bob's addresses. The setup interval is the difference between
those times, and the maximum setup interval is the largest of
those intervals.</t>
<!-- The units of measurement MUST be clearly stated. -->
<t hangText="Units:">Session setup time is measured in
milliseconds.</t>
<!-- If the measurement is specific to a measurement point this SHOULD be defined. The measurement domain MAY also be defined. Specifically, if measurement points are spread across domains, the measurement domain (intra-, inter-) is another factor to consider. In some cases, the measurement requires multiple measurement points: all measurement points SHOULD be defined, including the measurement domain(s). -->
<t hangText="Measurement Point(s):">The measurement point is at
Alice's LAN interface, observed using a program such as tcpdump
running on Alice or an external analyzer.</t>
<!-- The acceptable range of timing intervals or sampling intervals for a measurement and the timing accuracy required for such intervals MUST be specified. Short sampling intervals or frequent samples provide a rich source of information that can help to assess application performance but may lead to excessive measurement data. Long measurement or sampling intervals reduce the amount of reported ... -->
<t hangText="Timing:">Continuous.</t>
</list></t>
</section>
<section anchor="Min-metric"
title="Metric: Minimum Session Setup Interval">
<t><list style="hanging">
<!-- The normative part of a metric definition MUST define at least the following: -->
<!-- Metric names MUST be unique within the set of metrics being defined and MAY be descriptive. -->
<t hangText="Name:">Minimum Session Setup Interval</t>
<!-- The description MUST explain what the metric is, what is being measured and how this relates to the performance of the system being measured. -->
<t hangText="Description:">The minimum session setup interval is
the shortest period of time observed for the opening of a
session.</t>
<!-- This method of measurement or calculation MUST define what is being measured or computed and the specific algorithm to be used. Does the measurement involve active or only passive measurements? Terms such as "average" should be qualified (e.g. running average or average over some interval). ... Some parameters linked to the method MAY also be reported, in order to fully interpret the performance metric. For example, the time interval, the load, the minimum packet loss, etc... -->
<t hangText="Methodology:">In the LAN analyzer trace, note the
times of the initial DNS request and the confirmation that the
session is open as described in <xref
target="procedure"></xref>. Several instances of the test will
be run, in at least one of which an attempt is seen to exactly
one of Bob's addresses. The setup interval is the difference
between those times, and the minimum setup interval is the
smallest of those intervals.</t>
<!-- The units of measurement MUST be clearly stated. -->
<t hangText="Units:">Session setup time is measured in
milliseconds.</t>
<!-- If the measurement is specific to a measurement point this SHOULD be defined. The measurement domain MAY also be defined. Specifically, if measurement points are spread across domains, the measurement domain (intra-, inter-) is another factor to consider. In some cases, the measurement requires multiple measurement points: all measurement points SHOULD be defined, including the measurement domain(s). -->
<t hangText="Measurement Point(s):">The measurement point is at
Alice's LAN interface, observed using a program such as tcpdump
running on Alice or an external analyzer.</t>
<!-- The acceptable range of timing intervals or sampling intervals for a measurement and the timing accuracy required for such intervals MUST be specified. Short sampling intervals or frequent samples provide a rich source of information that can help to assess application performance but may lead to excessive measurement data. Long measurement or sampling intervals reduce the amount of reported ... -->
<t hangText="Timing:">Continuous.</t>
</list></t>
</section>
<section anchor="Variation-metric"
title="Descriptive Metric: Attempt pattern">
<t><list style="hanging">
<!-- The normative part of a metric definition MUST define at least the following: -->
<!-- Metric names MUST be unique within the set of metrics being defined and MAY be descriptive. -->
<t hangText="Name:">Attempt pattern</t>
<!-- The description MUST explain what the metric is, what is being measured and how this relates to the performance of the system being measured. -->
<t hangText="Description: ">The Attempt Pattern is a description
of the observed pattern of attempts to open the session. In
simple cases, it may be something like "Initial TCP SYNs to a
new address were observed every <so many> milliseconds";
in more complex cases, it might be something like "Initial TCP
SYNs in IPv6 were observed every <so many> milliseconds,
and other TCP SYNs using IPv4 were observed every <so
many> milliseconds, but the two sequences were independent."
It may also comment on retransmission patterns if observed.</t>
<!-- This method of measurement or calculation MUST define what is being measured or computed and the specific algorithm to be used. Does the measurement involve active or only passive measurements? Terms such as "average" should be qualified (e.g. running average or average over some interval). ... Some parameters linked to the method MAY also be reported, in order to fully interpret the performance metric. For example, the time interval, the load, the minimum packet loss, etc... -->
<t hangText="Methodology:">The traffic trace is analyzed to
determine the pattern of initiation.</t>
<!-- The units of measurement MUST be clearly stated. -->
<t hangText="Units:">milliseconds.</t>
<!-- If the measurement is specific to a measurement point this SHOULD be defined. The measurement domain MAY also be defined. Specifically, if measurement points are spread across domains, the measurement domain (intra-, inter-) is another factor to consider. In some cases, the measurement requires multiple measurement points: all measurement points SHOULD be defined, including the measurement domain(s). -->
<t hangText="Measurement Point(s):">The measurement point is at
Alice's LAN interface, observed using a program such as tcpdump
running on Alice or an external analyzer.</t>
<!-- The acceptable range of timing intervals or sampling intervals for a measurement and the timing accuracy required for such intervals MUST be specified. Short sampling intervals or frequent samples provide a rich source of information that can help to assess application performance but may lead to excessive measurement data. Long measurement or sampling intervals reduce the amount of reported ... -->
<t hangText="Timing:">Continuous.</t>
</list></t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
<t>Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during the RFC
publication process. From the author"s perspective, it may therefore be
removed upon publication as an RFC at the RFC Editor"s discretion.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This note doesn't address security-related issues.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This note was discussed with Dan Wing, Andrew Yourtchenko, and
Fernando Gont. In the Benchmark Methodology Working Group, Al Morton,
David Newman, and Sarah Banks made comments.</t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="-00 Version:">Initial version - November, 2010</t>
<t hangText="-01 Version:">Rewritten per suggestions by Al Morton
and David Newman.</t>
</list></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.I-D.wing-v6ops-happy-eyeballs-ipv6" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0791" ?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.2827" ?>
<?rfc include="reference.RFC.3493" ?>
<?rfc include="reference.RFC.5461" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:21:43 |