Internet DRAFT - draft-v6ops-xie-network-happyeyeballs
draft-v6ops-xie-network-happyeyeballs
Internet Engineering Task Force C. Xie
Internet-Draft China Telecom
Intended status: Standards Track L. Song
Expires: March 24, 2019 Beijing Internet Institute
September 20, 2018
Network-side Happy Eyeballs based on accurate IPv6 measurement
draft-v6ops-xie-network-happyeyeballs-00
Abstract
During the period of IPv6 transition, both ISP and ICP (Internet
Content Provider) care about user's experience in dual-stack network.
They hesitate to provide IPv6 to their users due to the fear of poor
IPv6 performance. Network-based Happy Eyeballs (NHE) is proposed in
this memo as a approach to provide better connectivity to end users
by doing accurate measurement and comparison on IPv6/IPv4 performance
on the network side other than client-side Happy Eyeballs (HE)
([RFC8305]). It works independently with client's adoption of HE.
REMOVE BEFORE PUBLICATION: The source of the document with test
script is currently placed at GitHub [NHE-GitHub]. Comments and pull
request are welcome.
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 https://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 March 24, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xie & Song Expires March 24, 2019 [Page 1]
Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview of NHE Mechanism . . . . . . . . . . . . . . . . . . 3
3. NHE DNS Resolver . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv6/IPv4 Performance Measurement . . . . . . . . . . . . . . 5
4.1. Performance metrics . . . . . . . . . . . . . . . . . . . 5
4.2. NHE Location considerations . . . . . . . . . . . . . . . 6
4.3. Less measurement traffic . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
During the period of IPv6 transition, both ISP and ICP (Internet
Content Provider) care about user's experience in dual-stack network.
They hesitate to provide IPv6 to their users due to the fear of poor
IPv6 performance. Happy Eyeballs(HE) [RFC8305] provides an approach
to enable clients to attempt multiple connections in parallel. It is
helpful to work around the blocked, broken, or sub-optimal network.
Taken IPv6 priority consideration in design, HE helps increase IPv6
traffic in network and reduce the delay in client side as well if
IPv6 connectivity is poorer. So far, most modern web browser support
HE very well, thanks to popular web browser engines, such as WebKit
and Trident. However, in practice there are still some bars keeping
application developers who develop Apps with APIs and libs which does
not implementing HE.
Firstly, HE adds additional complexity and uncertainties to both
development and operation. For example, according to the section 8
of RC8305 there are 6 Configurable values such as Resolution Delay
and Connection Attempt Delay. It raise a bar for small application
developers to do a "nuanced implementation" to tune these values
according to network dynamics or history RTT data. Secondly,
paralleled connections emitted by HE will produce larger volume of
Xie & Song Expires March 24, 2019 [Page 2]
Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018
traffic which consume both mobile fees and power. As a result mobile
application developers may choose no to adopt HE or even not consider
migrating their APPs to IPv6 due to the issues. It is typical case
in regions where IPv6 performance is not as good as IPv4 in terms of
RTT and failure rate.
This draft is intend to proposed an Network-side Happy Eyeballs(NHE),
an approach to address the same problem targeted by Client-side Happy
eyeballs ([RFC8305]) for IPv4/IPv6 dual-stack users. Instead of
requiring the client to race IPv6 and IPv4 connections, NHE intends
to do the "race" on the network side in advance and do selective
filtering of the DNS AAAA record for specific domains. The rationale
of NHE approach is simple that ISPs typically the mobile network
provider has more resource, capability and motivation to do accurate
IPv6/IPv4 performance measurement for the good of their users. With
sufficient and accurate IPv6/IPv4 performance information, ISPs can
make confident decision to filter AAAA record or not.
It is worth to mention that with NHE approach, the operational issues
will not be hidden and ISP will be crystal clear about their IPv6
network performance and spare no effort to improve it.
2. Overview of NHE Mechanism
Figure 1 shows the high level diagram of NHE. NHE mechanism involve
two key components: NHE DNS Resolver and IPv6/IPv4 measurement. In
NHE DNS resolver a special list of domains is maintained. The
purpose of this list is to indicate the resolver performing AAAA
record filtering (returning NODATA) if AAAA record exists for that
domain in the list. This special list is updated via a Push (or
Pull) interface from IPv6/IPv4 measurement component. The list is
called NHE filtering list in this document.
The component of IPv6/IPv4 measurement is designed to feed the NHE
filtering list, by performing IPv6/IPv4 RTT measurement on each
cached domains. The cached domains under the measurement can start
with a well populated cache, then updated in align with the resolver
cache via a Push (or Pull) interface from NHE DNS resolver. The
criteria of putting a specific domain into that list and how to
perform the measurement are introduced in Section 4.
Xie & Song Expires March 24, 2019 [Page 3]
Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018
+--------------------------------+
| |
| IPv6/IPv4 Measurement |
| |
+--------------+-----------------+
^ |
Cached domains | | Domains with poor
| | IPv6 connections
| |
| v
NODATA +-----------------------+
<-----------+ | |
| NHE DNS Resolver |
+------------> | |
a query for AAAA +-----------------------+
record of a domain
Figure 1: High-Level NHE Mechanism
When the two component of NHE are ready, then the processing is
described as follows: Once NHE DNS Resolver receive a AAAA record
query from client, the resolver firstly check if the qname matches a
entry or not in the NHE filter list. If the qname matches an entry,
then the AAAA record will be filtered and a NODATA response will be
replied. If no entry is matched, then NHE DNS resolver will response
as a normal resolver.
Note that NHE can work independently with the Client's adoption of
HE. It can push the clients to fall back faster to IPv4 if they does
not support HE. It also can help reduce the unnecessary traffic
emitted by HE client.
3. NHE DNS Resolver
Before [RFC6555] and [RFC8305] were documented, selective filtering
of the DNS AAAA record was proposed as a practice making the IPv6
transition less painful [Less-painful]. The basic idea introduced is
that ISP DNS Recursive servers does not return AAAA for users who
have broken IPv6 connectivity. There are some working
implementations of it such filter AAAA option in BIND 9
[Filtering-AAAA]
Note that in the beginning, it was widely considered difficult to
accurately measure working users. So ISP resolver only returns AAAA
if the AAAA query came over IPv6. However, even ISP resolver can
receive queries from stub client via IPv6, The end-to-end IPv6
connectitity from the client to far-end server may be poor as well
Xie & Song Expires March 24, 2019 [Page 4]
Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018
due to the issues on either authoritative server (servfail for
exmaple), or content provider network, or the path in the midst.
NHE DNS resolver adopts selective filtering of the DNS AAAA record as
well. However, approach like filter AAAA option does not fit NHE
scenarios, because NHE is expected to filter AAAA option based on the
qname of the query, not the transport protocol or addresses where the
query come from. The difference is that a qname list (referred as to
NHE filtering list) is maintained and updated periodically by NHE DNS
resolver. It has an interface with IPv6/IPv4 performance measurement
which can push the newest list to NHE DNS Resolver.
Besides the Push(or Pull) interface from the measurement , NHE DNS
resolver can also Push(or Pull) populated cache to the measurement
component as shown in figure 1. The cache pushed by resolver can be
optionally companied with additional information like RTT of NS for
each domain and number of cache hits. The additional information can
be used to reduce measuring traffic which is introduced in
Section 4.3
4. IPv6/IPv4 Performance Measurement
An accurate IPv6 performance measurement is vital to the success of
NHE. A accurate measurement depends on what to measure, where and
how to measure.
4.1. Performance metrics
In client-side HE, a kind of round-trip delay or round-trip time(RTT)
metric is used where a race between IPv6 and IPv4 connection is
measured, starting from hostname resolution, then TCP setup on both
address families. In NHE, the similar approach is adopted in ISP
network to simulate a client doing race for a list of domains.
o Lookup the hostname. If a positive AAAA response with at least
one valid AAAA record is received, it process next. If a negative
response with no AAAA record is received, it will break and mark
the domain whose AAAA record should be filtered. Note that if a
negative response with Servfail is received, no Servfail response
should be return to the client, because it is observed that some
clients will continue asking AAAA queries after receiving Servfail
response.
o Make TCP connections via all IPv6 and IPv4 destination addresses
returned. Note that in NHE there is no address sorting or
connection attempt Delay which are important in the design of
client-side HE. NHE measuring server can concurrently make
connections on all addresses returned.
Xie & Song Expires March 24, 2019 [Page 5]
Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018
o The round-trip delay is measured including the RTT of hostname
resolution and RTT of TCP setup (start from sending the SYN and
end by ACK is received). If there is more than one IP address in
either AAAA or A record response, all distance addresses should be
measured for round-trip delay.
o Calculate the difference of round-trip delay (Diff-RTT) of
different address family. If there are more than one IP address
in either AAAA or A record response, the minimum RTT of a
destination from one address family will be chosen to do the
difference, that is Min(RTT-IPv6)-min(RTT-IPv4)
o For each domain, if the difference of round-trip delay of IPv6 and
IPv4 is larger than a configurable threshold, the domain will be
listed in the NHE filtering list to be synchronized to NHE DNS
resolver. Note that the threshold value should be tunable by
network provider to gain a better tradeoff between IPv6
performance and IPv6 priority practice.
In the measurement process described above, there is a important
domain list called Measuring list which contains the targeted
domains. The list can be formed from the popular domains in the
cache pushed from the resolver or configured by operators from other
source. It is not necessary to keep the Measure list and cache
pushed by resolver identical. This measurement can be done
periodically on a specific domain, for example one hour or two, and
make it ready for Push to NHE DNS resolver. Note that no protocol is
specified in this memo which is used to synchronized NHE Filtering
list and cached domains in resolver.
Compared to Client-side HE, NHE operated by ISP operators has more
resource to do better performance measurement. The race on the
handset measure the round-trip delay on one instantaneous connection
which does not fully represent the connectivity performance of one
address family in a persistent period. For example erratic variation
in delay (caused by network jitter) makes it difficult to support
many interactive real-time applications. So the statistics of round-
trip delay is helpful for ISP operator to build more sophisticated
measurement. Section 4 of [RFC2681] specifies some statistics
definitions for round-trip delay which can be utilized for advanced
Round-trip delay measurement, such as percentile, median, minimum,
inverse percentile etc.
4.2. NHE Location considerations
According to the accuracy requirement of user performance simulation,
the location where the measurement is done is very important. The
intuitive approach is to placed the measuring probes or servers on
Xie & Song Expires March 24, 2019 [Page 6]
Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018
the edge, in proximity to the end users. In 4G LTE cellular network
as a typical case, the performance measurement server can be located
in proximity of base stations (or an aggregation point). There is
only at most one hop difference in the end-to-end path between a real
end user and a destination.
There is one question about the location of NHE deployment. If
performance measurement server is located on the edge, is NHE
resolver should be located in the same place? In another word: are
they deployed in pairs? The simple answer is yes which enhance the
efficiency of cache if the resolver is deployed on the edge. NHE DNS
resolver can be a cache sever forwarding cache missed query to the
ISP normal full functional resolver. The only concern is if the
caching resolver is located closely to end users, it may lose good
cache hit probability.
4.3. Less measurement traffic
Since the IPv6/IPv4 performance varies per domain, there is a fear of
having to generate a lot of measuring traffic in NHE. There are two
approaches may be helpful to generate less traffic. One is to keep a
moderate size of NHE filtering list including, for example, top 1k ~
5k popular domains in the cache. To achieve that, the NHE resolver
should not only Push the cache , but also a popularity value of each
domain (the number of cache hits). In addition, the size of the
filtering list generated by measurement server can be configurable as
well according to ISP local policy.
The second approach to reduce the measurement traffic is to use
passive measurement. The round-trip delay of DNS lookup of a
particular domain is trivial in most of case if cache hit. So
passive measurement should focus on monitoring TCP connection of
specific destination. Suppose there are 1000 top popular domains in
the measurement list which means thousands TCP connections is to be
put into passive monitoring to measure the round-trip delay.
One optional approach of limiting the size of measuring list is to
focus on top Apps other than top domains. ISP can cooperated with CP
to maintain a domain list of top Apps for NHE.
5. Security Considerations
NHE adopt filtering in the resolver so it will break DNSSEC and omit
RRSIG records covering type AAAA as well as AAAA record. The scope
of DNSSEC break is limited between client and resolver, which is not
the typical scenario of DNSSEC though, in the case clients ask for
RRSIG record of AAAA.
Xie & Song Expires March 24, 2019 [Page 7]
Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018
Filtering AAAA records cause DNS incoherency in the end users
perspective which may causes some risks if end user's application
depend on the integrity of DNS data. To reduce this risk, ISP
resolver would artificially delay the AAAA answers if positive answer
is received.
6. IANA considerations
No IANA considerations for this memo
7. Acknowledgments
Acknowledgments are given to Geoff Huston, David Schinazi, Marc
Blanchet, and Paul Vixie who gave comments and suggestions on this
memo.
8. References
[Filtering-AAAA]
"Filter AAAA option in BIND 9", August 2017,
<https://kb.isc.org/docs/aa-00576>.
[Less-painful]
Yahoo, "IPv6 and recursive resolvers:How do we make the
transition less painful?", March 2010,
<https://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>.
[NHE-GitHub]
BII, "GitHub Repository of Network-side Happy Eyeballs",
<https://github.com/songlinjian/
Network-based-Happyeyeballs>.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <https://www.rfc-editor.org/info/rfc6555>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
Xie & Song Expires March 24, 2019 [Page 8]
Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018
Authors' Addresses
Chongfeng Xie
China Telecom
No.118 Xizhimennei street, Xicheng District
Beijing 100035
P. R. China
Email: xiechf.bri@chinatelecom.cn
Linjian Song
Beijing Internet Institute
2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA
Beijing 100176
P. R. China
Email: songlinjian@gmail.com
Xie & Song Expires March 24, 2019 [Page 9]
