[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-v6ops-xie-network-happyeyeballs) 00 01

Internet Engineering Task Force                                   C. Xie
Internet-Draft                                             China Telecom
Intended status: Informational                                   L. Song
Expires: May 29, 2019                         Beijing Internet Institute
                                                       J. Palet Martinez
                                                        The IPv6 Company
                                                       November 25, 2018


     Network-side Happy Eyeballs based on accurate IPv6 measurement
                draft-xie-v6ops-network-happyeyeballs-01

Abstract

   During the period of IPv6 transition, both ISPs and ICPs (Internet
   Content Providers) care about user's experience in dual-stack
   networks.  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 an approach to facilitate ISPs to identify
   IPv6 connectivity issues and provide better connectivity to end
   users.  NHE does accurate measurements and comparison on IPv6/IPv4
   performance on the network side compared with client-side as in Happy
   Eyeballs v2 (HEv2) [RFC8305].  It works independently with client's
   adoption of HEv2 and both coexist without conflicting.

   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 May 29, 2019.






Xie, et al.               Expires May 29, 2019                  [Page 1]


Internet-DraftNetwork-side Happy Eyeballs based on accurateNovember 2018


Copyright Notice

   Copyright (c) 2018 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
   (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 Framework . . . . . . . . . . . . . . . . . .   3
   3.  IPv6/IPv4 Performance Measurement . . . . . . . . . . . . . .   4
     3.1.  Performance metrics . . . . . . . . . . . . . . . . . . .   4
     3.2.  Location of IPv6/IPv4 Measurement . . . . . . . . . . . .   6
     3.3.  Reducing measurement traffic  . . . . . . . . . . . . . .   7
   4.  Reporting IPv6 failures using syslog  . . . . . . . . . . . .   7
     4.1.  Discovery of the syslog collector NSP . . . . . . . . . .   8
   5.  One Use Case of Troubleshooting action  . . . . . . . . . . .   8
   6.  Security considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   During the period of IPv6 transition, both ISPs and ICPs (Internet
   Content Providers) care about user's experience in dual-stack
   networks.  They hesitate to provide IPv6 to their users due to the
   fear of poor IPv6 performance.  Happy Eyeballs v2 (HEv2) [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.  Taking IPv6 priority consideration
   in design, HEv2 helps increase IPv6 traffic in networks and reduce
   the delay in client side as well if IPv6 connectivity is poorer.  So
   far, most modern web browsers support HEv2 very well, thanks to
   popular web browser engines, such as WebKit and Trident.  However, in
   practice there are still some barriers keeping Mobile developers who
   develop Apps with APIs and libs which don't not implementing HEv2.




Xie, et al.               Expires May 29, 2019                  [Page 2]


Internet-DraftNetwork-side Happy Eyeballs based on accurateNovember 2018


   Firstly, HEv2 adds additional complexity and uncertainties to both
   development and operation.  For example, according to the section 8
   of [RFC8305] there are 6 Configurable values such as Resolution Delay
   and Connection Attempt Delay.  It raises a bar for small application
   developers to do a "nuanced implementation" to tune these values
   according to network dynamics.  Secondly, paralleled connections
   emitted by HEv2 produces larger volume of traffic which consume both
   mobile fees and power.  As a result, mobile application developers
   may choose not to adopt HEv2 or postpone their IPv6 transition due to
   those issues.  The third, client-based HEv2 hides some of the
   possible IPv6 connectivity issues to the operator, because users
   don't notice anything broken, so they aren't reporting it to their
   providers.  Those issues are more notable in regions where IPv6
   performance is not as good as IPv4 in terms of RTT and failure rate
   [APNIC-v6perf].

   This memo is intended to proposed a Network-side Happy Eyeballs
   (NHE), an approach to improve IPv6 connectivity by doing network-side
   IPv6 measurement and failure reporting.  Instead of requiring the
   client to race IPv6 and IPv4 connections, NHE intends to do the
   "race" on the network side.  NHE aims to provide helpful alert
   information for ISP to fix the networking issues by themselves.  In
   addition, this memo also introduces a potential use case of NHE to
   work around networking issues which can't be resolved locally (issues
   of third parties on the path to the destination, or the destination
   itself, for example).

   The rationale of NHE approach is simple.  Considering that ISPs
   typically the mobile and broadband network providers have more
   resources, capability and motivation to do accurate IPv6/IPv4
   performance measurement, using existing protocols for the immediate
   alert/reporting of failures, those can then be analyzed and resolved,
   improving network reliability, for the good of their users.  With
   sufficient and accurate troubleshooting information, ISPs will have a
   crystal clear vision about their IPv6 network performance and spare
   no effort to improve it.

2.  Overview of NHE Framework

   As shown in Figure 1 NHE Frame consists of three key components:
   IPv6/IPv4 performance measurement, IPv6 failure reporting and
   troubleshooting actions on these failures.  To resolve the issue of
   Client-based HEv2 concealing the operational issues of IPv6 network,
   IPv6 failure reporting is a key element in NHE, by reporting and
   collecting precise performance information of the IPv6 network.  Note
   that IPv6 failure event is not necessary only triggered by
   disconnection or severe packet dropping.  It includes all events once




Xie, et al.               Expires May 29, 2019                  [Page 3]


Internet-DraftNetwork-side Happy Eyeballs based on accurateNovember 2018


   IPv6 connection is slower than IPv4 in the race.  Section 4 will
   introduce more about how IPv6 failure reporting works.

   The IPv6/IPv4 performance measurement component is designed to feed
   IPv6 failure reporting, by performing IPv6/IPv4 RTT measurement on a
   special list of domains (called measuring list).  The list of domains
   under the measurement can start with a well populated cache, then
   updated in alignment with a certain dynamic popularity of Domains in
   the network.  To achieve better accuracy of measurement, probes may
   be located adjacent to clients on the edge of the network.  The
   criteria of putting a specific domain into that list and how to
   perform the measurement are introduced in Section 3.



     +-------------+     +--------------+     +---------------+
     | IPv6/IPv4   +---> | IPv6 Failure +---> |Troubleshooting|
     | Measurement |     |   Reporting  |     |    Actions    |
     +-------------+     +--------------+     +---------------+


                    Figure 1: High-Level NHE Framework

   After IPv6 failure information is collected and analyzed, various
   troubleshooting actions can be adopted accordingly.  Most of the
   actions are similar to IPv4 network troubleshooting.  For example, if
   the problem is local, operators should resolve the networking issue
   as soon as possible.  If the problem is caused by far-end or third-
   parties, the ISP may check the upstream ISPs or transit peering ASs
   to clear the issue (withdraw some BGP peerings for example).  There
   is a case with an action which can be adopted temporarily to reduce
   the suffering of IPv6 poor performance for a specific domain.  It
   will be introduced in Section 5.

   Note that NHE can work independently with client's adoption of HEv2
   and both coexist without conflicting in the NHE framework.

3.  IPv6/IPv4 Performance Measurement

   An accurate IPv6 performance measurement is vital to the success of
   NHE.  An accurate measurement depends on what to measure, where and
   how to measure.

3.1.  Performance metrics

   In client-side HEv2, 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 the domain name resolution,



Xie, et al.               Expires May 29, 2019                  [Page 4]


Internet-DraftNetwork-side Happy Eyeballs based on accurateNovember 2018


   then the TCP setup on both address families.  In NHE, a similar
   approach is adopted in the ISP network to simulate a client doing a
   race for a list of domains.

   o  Lookup the domain name.  If a positive AAAA response with at least
      one valid AAAA record is received, it continues the process.  If a
      negative response with no AAAA record is received, it will break
      and continue with another domain in the list.  Note that, if a
      negative response with ServFail is received, which means error on
      the far-end server, it should be marked "alert to operator" to
      report "ServFail" incident.  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 HEv2.  NHE measuring server can concurrently make
      connections on all addresses returned.

   o  The round-trip delay is measured including the RTT of the domain
      name resolution and the RTT of the TCP setup (started when sending
      the SYN and ending when the ACK is received).  If there is more
      than one IP address in either the AAAA or A record responses, all
      the addresses should be measured for the round-trip delay.

   o  Calculate the difference of round-trip delay (Diff-RTT) of
      different address families.  If there are more than one IP address
      in either the AAAA or A record responses, 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 the round-trip delay of IPv6
      and IPv4 is larger than a configurable threshold, the domain will
      be recorded in a local list and flagged as "alert to operator"
      with "Poor IPv6 Performance" incident.  This action will trigger
      the reporting algorithm (described in section 4).  If the domain
      is already listed in the local list with a flag "alert to
      operator", nothing should be done (in order to avoid repetitive
      alerts).

   o  When a follow-up measurement result shows that, for a given
      domain, which was previously flagged as "alert to operator", there
      is no longer an issue, the "alert to operator" flag must be
      cleared and the reporting algorithm will be triggered.

   Note that the threshold value should be tunable by the network
   provider to gain a better tradeoff between IPv6 vs IPv4 performance
   and allow to adjust the IPv6 vs IPv4 priority local policy.



Xie, et al.               Expires May 29, 2019                  [Page 5]


Internet-DraftNetwork-side Happy Eyeballs based on accurateNovember 2018


   In the measurement process described above, there is an important
   domain list called Measuring list which contains the targeted
   domains.  The list can be formed and updated from the popular domains
   visited by users of the network.  This measurement should be done
   periodically on each domain, every a given configurable number of
   hours.

   Compared to Client-side HEv2, NHE operated by ISPs have more
   resources to do better performance measurement.  For exmaple, the
   race on the handset measures 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 are helpful
   for ISPs to build more sophisticated measurements.  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.

   Also, HEv2 measurements may be influenced by access network problems,
   which don't affect NHE measurements.  The ISP should measure the
   access network problems using alternative means.

3.2.  Location of IPv6/IPv4 Measurement

   According to the accuracy requirement of user performance simulation,
   the location where the measurement is done is very important.  The
   intuitive approach is to place the measuring probes or servers on the
   edge, in proximity to the end users.  In 4G LTE cellular networks as
   a typical case, the performance measurement servers can be located in
   proximity to 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.

   In the case of broadband networks,the measuring probes can be
   collocated with the BRAS, OLTs, or equivalent aggregation points,
   depending on each access technology.

   Setting up probes at different parts of the network, including core,
   or close to the upstream provider connectivity, can help to determine
   the source of the issues, especially if they affect many domains.

   Moreover, probes can be designed into a special mobile device for
   reporting purpose.  There are many choices.  For example, people can
   implement a specially application to do the probing and reporting to
   a collector operated by the operator.  Modern APM (application
   performance measurement) and NPM (network performance measurement)



Xie, et al.               Expires May 29, 2019                  [Page 6]


Internet-DraftNetwork-side Happy Eyeballs based on accurateNovember 2018


   technologies allow normal application software integrated with
   special SDK (Software Development Kit) for measuring purposes.  So,
   it is possible for mobile App providers to adopt NHE framework to
   avoid IPv6 poor performance by themselves, although the
   troubleshooting actions are different from the one on the ISP case.

3.3.  Reducing 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 that may be helpful to generate less traffic.  One is to
   keep a moderate size of Measuring list list including, for example,
   the top 1k popular domains in the cache.  The size of the Measuring
   list can be configurable as well according to the ISP local
   policy.One optional approach to limit the size of the measuring list
   is to focus on top 1k Apps other than domains.  ISPs can cooperate
   with ICPs to maintain a domain list of top Apps for NHE.

   The second approach to reduce the measurement traffic, is to use
   passive measurements.  The round-trip delay of DNS lookup of a
   particular domain is trivial in most of the cases if there is a cache
   hit.  So passive measurement should focus on monitoring TCP
   connection of specific destinations.  Suppose there are 1000 top
   popular domains in the measurement list, which means a thousand of
   TCP connections will be inserted into the passive monitoring to
   measure the round-trip delay.

4.  Reporting IPv6 failures using syslog

   In order to simplify the reporting of the NHE failures, syslog
   ([RFC5424]) over UDP ([RFC5426]), MUST be used, by means of the
   default port (514) with IPv6-only.

   The intent is to make this reporting very simple, so no choice of
   alternative ports or transport protocols is offered.

   Operators willing to use this reporting MUST configure at least one
   syslog collector.

   The configuration can be done in a static way, providing dedicated
   IPv4/IPv6 addresses for the syslog collectors and probes.

   As an alternative, a more automated procedure can be done by
   configuring at least one syslog collector at the IPv6 prefix formed
   as:

   Network-Specific Prefix::192.88.99.1




Xie, et al.               Expires May 29, 2019                  [Page 7]


Internet-DraftNetwork-side Happy Eyeballs based on accurateNovember 2018


   The Network-Specific Prefix (NSP) MUST be chosen by the operator from
   its RIR allocated IPv6 addressing space.

   Additional collectors can be made available by using anycast at the
   NSP + 192.88.99.0/24 prefix

   Note that messages encoded in syslog are to be defined.  As
   introduced in Section 3.1, syslog of NHE should contain two kinds of
   message to report "Poor IPv6 Performance" incident and "ServFail"
   incident.

4.1.  Discovery of the syslog collector NSP

   In case the automated procedure is used, the same mechanism described
   by RFC7050 ([RFC7050]) should be used to look for the address of the
   syslog collector(s).

   Because the collectors will be using an IPv6 address with the 32 low
   order bits from the reserved range 192.88.99.0/24, this will not be
   in conflict with any public addresses used in Internet, so this
   mechanism is compatible with the expected usage of the NSP for NAT64.

5.  One Use Case of Troubleshooting action

   Besides the normal network troubleshooting measures taken by network
   operators as usual in IPv4 networks, there are other troubleshooting
   actions for temporary but urgent workarounds.

   Before [RFC6555] and [RFC8305] were documented, selective filtering
   of the DNS AAAA record (returning NODATA) 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 such filter AAAA option in BIND 9
   [Filtering-AAAA].

   However, it should be noticed that there are two security risks on
   selective filtering.  One is that it may break DNSSEC and omit RRSIG
   records covering type AAAA as well as AAAA record.  The second is
   that 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 both security risks, an alternative approach for an ISP
   using NHE, could be to run a special resolver which artificially
   delays the AAAA answers of a targeted domain name.  A domain name
   being targeted means that the IPv6 performance of that domain name is
   measured and reported with poor performance.  So, instead of



Xie, et al.               Expires May 29, 2019                  [Page 8]


Internet-DraftNetwork-side Happy Eyeballs based on accurateNovember 2018


   filtering the AAAA record, postponing the AAAA responses with a
   configurable timer (i.e., 300 ms) may cause IPv6 connection losing
   the race on the client side which avoid Concurrent IPv6 and IPv4
   connection attempts.  It will help the HEv2 client.  The non-HE
   client will fall back sooner to IPv4 without IPv6 connections and
   retries.

   Note that there is a corner case when negative response with ServFail
   are received for a domain name lookup, no ServFail response should be
   returned to the client, because it is observed that some clients will
   continue querying for AAAA RRs after receiving ServFail response.  In
   this case, the resolver could silently drop the query without
   responding to the client.

6.  Security considerations

   TBD

7.  IANA Considerations

   No IANA considerations for this memo

8.  Acknowledgments

   Acknowledgments are given to Geoff Huston, David Schinazi, Marc
   Blanchet, and Paul Vixie who gave comments and suggestions on the
   conception of NHE.

   Thanks to Tony Finch and Tommy Pauly who gave positive comment on the
   part which 01 version stands on.

9.  References

   [APNIC-v6perf]
              APNIC, "APNIC IPv6 Performance Monitoring",
              <stats.labs.apnic.net/v6perf>.

   [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>.






Xie, et al.               Expires May 29, 2019                  [Page 9]


Internet-DraftNetwork-side Happy Eyeballs based on accurateNovember 2018


   [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>.

   [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424,
              DOI 10.17487/RFC5424, March 2009,
              <https://www.rfc-editor.org/info/rfc5424>.

   [RFC5426]  Okmianski, A., "Transmission of Syslog Messages over UDP",
              RFC 5426, DOI 10.17487/RFC5426, March 2009,
              <https://www.rfc-editor.org/info/rfc5426>.

   [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>.

   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis",
              RFC 7050, DOI 10.17487/RFC7050, November 2013,
              <https://www.rfc-editor.org/info/rfc7050>.

   [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>.

Authors' Addresses

   Chongfeng Xie
   China Telecom
   No.118 Xizhimennei street, Xicheng District
   Beijing  100035
   P. R. China

   Email: xiechf.bri@chinatelecom.cn











Xie, et al.               Expires May 29, 2019                 [Page 10]


Internet-DraftNetwork-side Happy Eyeballs based on accurateNovember 2018


   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


   Jordi Palet Martinez
   The IPv6 Company
   Molino de la Navata, 75
   Madrid, La Navata - Galapagar  28420
   Spain

   Email: jordi.palet@theipv6company.com
   URI:   http://www.theipv6company.com/


































Xie, et al.               Expires May 29, 2019                 [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/