One document matched: draft-wing-http-new-tech-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.tuexen-sctp-udp-encaps SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tuexen-sctp-udp-encaps.xml">
<!ENTITY rfc4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY rfc2766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2766.xml">
<!ENTITY rfc4966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4966.xml">
<!ENTITY rfc4213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4213.xml">
<!ENTITY I-D.despres-6rd SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.despres-6rd.xml">
<!ENTITY I-D.ietf-softwire-dual-stack-lite SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-dual-stack-lite.xml">
<!ENTITY rfc4074 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4074.xml">
<!ENTITY I-D.ietf-mmusic-ice SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice.xml">
<!ENTITY I-D.natarajan-http-over-sctp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.natarajan-http-over-sctp.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-wing-http-new-tech-01" ipr="trust200902">
<front>
<title abbrev="Happy Eyeballs: Trending Towards Success">Happy Eyeballs:
Trending Towards Success (IPv6 and SCTP)</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Andrew Yourtchenko" initials="A." surname="Yourtchenko">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>De Kleetlaan, 7</street>
<city>San Jose</city>
<region>Diegem</region>
<code>B-1831</code>
<country>Belgium</country>
</postal>
<email>ayourtch@cisco.com</email>
</address>
</author>
<author fullname="Preethi Natarajan" initials="P." surname="Natarajan">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>prenatar@cisco.com</email>
</address>
</author>
<date year="2010" />
<workgroup>Applications Area</workgroup>
<abstract>
<t>People like their computers to work quickly. During the transition to
new technology, both old and new technologies have to peacefully
co-exist. However, if users experience connection delays attributed to
the new technology the new technology will be shunned.</t>
<t>HTTP ("The Web") is one of the most visible and time-critical
applications that is used by nearly every Internet user. It is critical
that new technologies which improve HTTP not impair or delay the display
of HTTP content. It is also important that users retain the ability to
share URIs amongst friends and colleagues, even if the other users have
not upgraded to the new technology.</t>
<t>This draft makes several recommendations to ensure user satisfaction
and a smooth transition from HTTP's pervasive IPv4 to IPv6 and from TCP
to SCTP.</t>
<t>The audience for this draft is application developers and content
providers. This draft is discussed on the Applications Discuss mailing
list, https://www.ietf.org/mailman/listinfo/apps-discuss.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In order to use HTTP successfully over IPv6 or SCTP, it is necessary
that the user enjoys nearly identical performance as compared to their
old technology (IPv4 and TCP). A combination of today's applications,
IPv6 tunneling and IPv6 service providers, IPv4 NAT, and some of today's
content providers all cause the user experience to suffer (<xref
target="problem_statement"></xref>). For IPv6, Google ensures a positive
user experience by using a DNS white list of IPv6 service providers who
peer directly with Google <xref target="whitelist"></xref>. However,
this is not scalable to all service providers worldwide, nor is it
scalable for other content providers to operate their own DNS white
list.</t>
<t>Instead, this document suggests a mechanism for applications to
quickly determine if IPv6, IPv4, SCTP, or TCP is the most optimal to
connect to a server. The suggestions in this document provide a user
experience which is superior to HTTP using TCP and IPv4, especially in
IPv6/IPv4 transition environment with dual stack hosts (e.g., <xref
target="RFC4213"></xref>, <xref
target="I-D.ietf-softwire-dual-stack-lite">DS-Lite</xref>, <xref
target="I-D.despres-6rd">6rd</xref>).</t>
<t>Once a certain address family is successful, it trends towards
preferring that address family. Thus, repeated use of the application
DOES NOT cause repeated probes over both address families.</t>
<t>The application recommendations in this document are primarily for
HTTP clients ("web browsers") and may also be helpful for other
applications.</t>
</section>
<section title="Notational Conventions">
<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 anchor="problem_statement" title="Problem Statement">
<t>As discussed in more detail in <xref target="problem_uris"></xref>,
it is important that the same URI and hostname be used for IPv4, IPv6,
SCTP, and TCP. Using separate namespaces causes namespace fragmentation
and reduces the ability for users to share URIs and hostnames, and
complicates printed material that includes the URI or hostname.</t>
<t>As discussed in more detail in <xref target="problem_ipv6"></xref>,
IPv6 connectivity is sometimes broken entirely or, due to tunnel
technologies might be slower than native IPv4 connectivity. However, due
to port limitations inherent in stateful IPv6/IPv4 translators [BEHAVE],
it is important that web browsers begin preferring IPv6 over IPv4 in
order to avoid those port limitations.</t>
<t>As discussed in more detail in <xref target="problem_sctp"></xref>,
there is no standard mechanism to indicate a host supports a non-TCP
transport protocol, such as SCTP.</t>
<section anchor="problem_uris" title="URIs and hostnames">
<t>URIs are often used between users to exchange pointers to content
-- such as on Facebook, email, instant messaging, or other systems.
Thus, production URIs and production hostnames containing references
to IPv4, IPv6, TCP, or SCTP will only function if the other party also
has application, OS, and a network that can access the URI or the
hostname.</t>
</section>
<section anchor="problem_ipv6" title="IPv6">
<t>When IPv6 connectivity is impaired, today's IPv6-capable web
browsers incur many seconds of delay before falling back to IPv4. This
harms the user's experience with IPv6, which will slow the acceptance
of IPv6, because IPv6 is frequently disabled in its entirety on the
end systems to improve the user experience.</t>
<t>Reasons for such failure include no connection to the IPv6
Internet, broken 6to4 or Teredo tunnel, and broken IPv6 peering. To
prevent this delay an experiment with IPv6 connectivity, content
providers use a separate namespace for their web server (e.g.,
ipv6.example.com), but doing that with production systems causes the
problems described in <xref target="problem_uris"></xref>.</t>
</section>
<section anchor="problem_sctp" title="SCTP">
<t>SCTP provides benefits over TCP <xref
target="I-D.natarajan-http-over-sctp"></xref>.</t>
<t>Unlike IPv6 which has an AAAA record, there is no DNS query that
indicates a host supports <xref target="RFC4960">SCTP</xref>, and HTTP
URI scheme is not extensible to support an SRV query that could
provide such support. Even if there was, it isn't possible to
determine if a middlebox, such as a firewall or a NAT, would block the
SCTP association.</t>
</section>
</section>
<section title="HTTP Client Recommendations">
<t>To provide fast connections for users, HTTP clients should make
connections quickly over various technologies, automatically tune itself
to avoid flooding the network with unnecessary connections (i.e., for
technologies that have not made successful connections), and
occasionally flush its self-tuning.</t>
<t>If an HTTP client supports IPv6 and SCTP (in addition to IPv4 and
TCP), the procedures described in <xref target="client_v6"></xref> and
<xref target="client_sctp"></xref> are performed together.</t>
<section anchor="client_v6" title="IPv6">
<t>This section details how to provide robust dual stack service for
both IPv6 and IPv4, so that the user perceives very fast application
response.</t>
<t>The HTTP client is configured with one value, P. A positive value
indicates a preference for IPv6 and a negative value indicates a
preference for IPv4. A value of 0 indicates equal weight, which means
the A and AAAA queries and associated connection attempts will be sent
as quickly as possible. The absolute value of P is the measure of a
delay before initiating a connection attempt on the other address
family. There are two P values maintained: one is application-wide and
the other is specific per each destination (hostname and port).</t>
<t>The algorithm attempts to delay the DNS query until it expects that
address family will be necessary; that is, if the preference is
towards IPv6, then AAAA will be queried immediately and the A query
will be delayed.</t>
<t>The HTTP client starts two threads in order to minimize the
user-noticeable delay ("dead time") during the connection
attempts:<list style="hanging">
<t hangText="thread 1: (IPv6)"><list style="symbols">
<t>If P<0, wait for absolute value of p*10 milliseconds</t>
<t>send DNS query for AAAA</t>
<t>wait until DNS response is received</t>
<t>Attempt to connect over IPv6 using TCP</t>
</list></t>
<t hangText="thread 2: (IPv4)"><list style="symbols">
<t>if P>0, wait for p*10 milliseconds</t>
<t>send DNS query for A</t>
<t>wait until DNS response is received</t>
<t>Attempt to connect over IPv4 using TCP</t>
</list></t>
</list></t>
<t>The first thread that succeeds returns the completed connection to
the parent code and aborts the other thread (<xref
target="abandon"></xref>).</t>
<t>After a connection is successful, we want to adjust the
application-wide preference and the per-destination preference. The
value of P is incremented (decremented) each time an IPv6 (IPv4)
connection is successfully made. When a connection using the
less-preferred address family is successful, it indicates the wrong
address family was used and the P is halved:<list style="symbols">
<t>If P>0 (indicating IPv6 is preferred over IPv4) and the
first thread to finish was the IPv6 thread it indicates the IPv6
preference is correct and we need to re-enforce this by increasing
the application-wide P value by 1. However, if the first thread to
finish was the IPv4 thread it indicates an IPv6 connection problem
occurred and we need to aggressively prefer IPv4 more by halving P
and rounding towards 0.</t>
<t>If P<0 (indicating IPv4 is preferred over IPv6) and the
first thread to finish was the IPv4 thread it indicates the
preference is correct and we need to re-enforce this gently by
decreasing the application-wide P value by 1. However, if the
first thread to finish was the IPv6 thread it indicates an IPv4
connection problem and we need to aggressively avoid IPv4 by
halving P and rounding towards 0.</t>
<t>If P=0 (indicating equal preference), P is incremented if the
first thread to complete was the IPv6 thread, or decremented if
the first thread to complete was the IPv4 thread.</t>
</list>After adjusting P, it should never be larger than 4 seconds
-- which is similar to the value used by many IPv6-capable HTTP
clients to switch to an alternate A or AAAA record.</t>
<t><list style="empty">
<t>Note: Proof of concept tests on fast networks show that even
smaller value (around 0.5 seconds) is practical. More extensive
testing would be useful to find the best upper boundary that still
ensures a good user experience.</t>
</list></t>
<!--
<t>An implementation of the IPv6/IPv4 Happy Eyeballs algorithm in the
Links web browser <xref target="links"></xref> is available at <xref
target="64-impl"></xref>.</t>
-->
</section>
<section anchor="client_sctp" title="SCTP">
<t>Due to the proliferation of NATs on the IPv4 Internet the best
success for SCTP can be achieved by attempting both native SCTP
connections and <xref
target="I-D.tuexen-sctp-udp-encaps">SCTP-over-UDP</xref>
connections.</t>
<t>For SCTP the following parameters are used:<list hangIndent="8"
style="hanging">
<t hangText="SWAIT:">Application-wide wait time for an SCTP
association attempt to complete. Default value of 50ms is
RECOMMENDED.</t>
<t hangText="PREF:">This denotes per-destination transport
preference. Possible values are "TCP", "SCTP", and "BOTH". Default
value of "BOTH" is RECOMMENDED.</t>
</list></t>
<t>The HTTP client starts several threads in order to minimize the
user-noticeable delay ("dead time") during the connection attempts.
The client starts one or more threads based on the following
logic:</t>
<t>If ((PREF == BOTH) or (PREF == SCTP)) start thread 1. If making a
connection using IPv4 start thread 2.</t>
<t>If ((PREF == BOTH) or (PREF == TCP)) start thread 3.</t>
<t><list style="hanging">
<t hangText=" thread 1 (SCTP):"><list style="symbols">
<t>Attempt to connect using SCTP (i.e., send SCTP INIT)</t>
</list></t>
<t hangText=" thread 2 (SCTP over UDP):"><list style="symbols">
<t>Attempt to connect using SCTP over UDP (i.e., send SCTP
INIT over UDP)</t>
</list></t>
<t hangText=" thread 3 (TCP):"><list style="symbols">
<t>Attempt to connect using TCP</t>
</list></t>
</list></t>
<t>If an SCTP association attempt was made by a thread, the HTTP
client waits for at least K ms; K = max(SWAIT, time taken for the TCP
connection to complete). If the TCP connection finishes during this
wait period, the HTTP client MAY choose TCP for the current HTTP
transfer but MUST wait until K ms to figure if the SCTP association
can be completed.</t>
<t>If the HTTP client did not choose TCP during the wait period and
the SCTP association completes successfully, the HTTP client prefers
SCTP over TCP connections and abandons the TCP connection.</t>
<t>After a connection is successful, we want to adjust the
per-destination preference for this destination. It is not recommended
to dynamically adjust the application-wide default value for SWAIT. If
the SCTP association was successful, set destination's PREF="SCTP",
else set PREF="TCP".</t>
</section>
</section>
<section title="Additional Considerations">
<t>This section discusses considerations and requirements that are
common to new technology deployment.</t>
<section title="Additional Network and Host Traffic">
<t>Additional network traffic and additional server load is created
due to these recommendations and mitigated by application-wide and
per-destination timer adjustments. The intent of this document is to
show how good user experience can be maintained while the
transitioning from IPv4 to IPv6, and transitioning from TCP to SCTP.
The good user experience is to the benefit of the user but to the
detriment of the network and server that are serving the user.</t>
</section>
<section anchor="abandon" title="Abandon Non-Winning Connections">
<t>It is RECOMMENDED that the non-winning connections be abandoned,
even though they could be used to download content. This is because
some web sites provide HTTP clients with cookies (after logging in)
that incorporate the client's IP address, or use IP addresses to
identify users. If some connections from the same HTTP client are
arriving from different IP addresses, such HTTP applications will
break. <list>
<t>Editor's note: If we can provide guidance to IPv6 and SCTP
developers that connections from the same client could arrive on
IPv4, IPv6, TCP, and SCTP we could eliminate the above paragraph.
But could we be sure all web sites would follow such guidance?</t>
</list></t>
</section>
<section title="Flush or Expire Cache">
<t>Because every network has different characteristics (working or
broken IPv6 connectivity, middlebox that permits or blocks SCTP, etc.)
the IPv6/IPv4 preference value (P) and the SCTP parameters (SWAIT and
PREF) SHOULD be reset to their default whenever the host is connected
to a new network. However, in some instances the application and the
host are unaware the network connectivity has changed (e.g., when
behind a NAT) so it is RECOMMENDED that per-destination values expire
after 10 minutes of inactivity.</t>
</section>
<section title="Determining Address Type">
<t>[[[ IS THIS SECTION NECESSARY ??</t>
<t>For some transitional technologies such as a dual-stack host, it is
easy for the application to recognize the native IPv6 address (learned
via a AAAA query) and the native IPv4 address (learned via an A
query). For other transitional technologies <xref
target="RFC2766"></xref> it is impossible for the host to
differentiate a transitional technology IPv6 address from a native
IPv6 address (see Section 4.1 of <xref target="RFC4966"></xref>).
Replacement transitional technologies are attempting to bridge this
gap. It is necessary for applications to distinguish between native
and transitional addresses in order to provide the most seamless user
experience.</t>
<t>]]]</t>
</section>
<section anchor="dns_behavior" title="DNS Behavior">
<t>Unique to DNS AAAA queries are the problems described in <xref
target="RFC4074"></xref> which, if they still persist, require
applications to perform an A query before the AAAA query. <list>
<t>[[Editor's Note: It is believed these defective DNS servers
have long since been upgraded. If so, we can remove this
section.]]</t>
</list></t>
</section>
<section title="Thread safe DNS resolvers">
<t>Some applications and some OSs do not have thread safe DNS
resolvers, which complicates implementation of simultaneous A and AAAA
queries for IPv4/IPv6.</t>
</section>
<section title="Middlebox Issues">
<t>Some devices are known to exhibit what amounts to a bug, when the A
and AAAA requests are sent back-to-back over the same 4-tuple, and
drop one of the requests or replies <xref
target="DNS-middlebox"></xref>. However, in some cases fixing this
behaviour may not be possible either due to the architectural
limitations or due to the administrative constraints (location of the
faulty device is unknown to the end hosts or not controlled by the end
hosts). The algorithm described in this draft, in the case of this
erroneous behaviour will eventually pace the queries such that this
issue is will be avoided. The algorithm described in this draft also
avoids calling the operating system's getaddrinfo() with "any", which
should prevent the operating system from sending the A and AAAA
queries on the same port.</t>
</section>
<section title="Multiple Interfaces">
<t>Interaction of the suggestions in this document with multiple
interfaces is for further study.</t>
</section>
</section>
<section title="Content Provider Recommendations">
<t>Content providers SHOULD provide both AAAA and A records for servers
using the same DNS name for both IPv4 and IPv6.</t>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>[[Placeholder.]]</t>
<t>See <xref target="abandon"></xref>.</t>
</section>
<section title="Acknowledgements">
<t>The mechanism described in this paper was inspired by Stuart
Cheshire's discussion at the IAB Plenary at IETF72, the author's
understanding of Safari's operation with SRV records, Interactive
Connectivity Establishment (<xref
target="I-D.ietf-mmusic-ice">ICE</xref>), and the current IPv4/IPv6
behavior of SMTP mail transfer agents.</t>
<t>Thanks to Fred Baker, Jeff Kinzli, Christian Kuhtz, and
Iljitsch van Beijnum for fostering the creation of this
document.</t>
<t>Thanks to Scott Brim and Stig Venaas for providing feedback on the
document.</t>
</section>
<section title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&I-D.tuexen-sctp-udp-encaps;
&rfc4960;
</references>
<references title="Informational References">
&rfc2766;
&rfc4966;
&rfc4213;
&I-D.despres-6rd;
&I-D.ietf-softwire-dual-stack-lite;
&rfc4074;
&I-D.ietf-mmusic-ice;
&I-D.natarajan-http-over-sctp;
<reference anchor="whitelist"
target="http://www.google.com/intl/en/ipv6">
<front>
<title>Google IPv6 DNS Whitelist</title>
<author fullname="Google" surname="Google">
<organization></organization>
</author>
<date month="March" year="2008" />
</front>
</reference>
<reference anchor="DNS-middlebox"
target="https://bugzilla.redhat.com/show_bug.cgi?id=505105">
<front>
<title>DNS middlebox behavior with multiple queries over same source
port</title>
<author fullname="Various" surname="Various">
<organization></organization>
</author>
<date month="June" year="2009" />
</front>
</reference>
<!--
<reference anchor="64-impl"
target="http://www.employees.org/~andin/happy-eyeballs">
<front>
<title>Implementation of Happy Eyeballs Algorithm in Links</title>
<author fullname="Andrew Yourtchenko" initials="A." surname="Yourtchenko">
<organization></organization>
</author>
<date month="July" year="2009" />
</front>
</reference>
<reference anchor="links"
target="http://links.sourceforge.net/">
<front>
<title>Links. The WWW Text Browser</title>
<author fullname="Sourceforge" surname="Sourceforge">
<organization></organization>
</author>
<date month="July" year="2009" />
</front>
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 00:49:53 |