IETF Logo Mail Archive

Re: [v6ops] An Update to Happy Eyeballs

Nick Chettle <nick@nccnetworks.co.uk> Thu, 09 March 2017 17:23 UTC

Return-Path: <nick@nccnetworks.co.uk>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E6C126D74 for <v6ops@ietfa.amsl.com>; Thu, 9 Mar 2017 09:23:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nccnetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghWDJelTJ50m for <v6ops@ietfa.amsl.com>; Thu, 9 Mar 2017 09:22:59 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10095.outbound.protection.outlook.com [40.107.1.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BA412966B for <v6ops@ietf.org>; Thu, 9 Mar 2017 09:22:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nccnetworks.onmicrosoft.com; s=selector1-nccnetworks-co-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OOiZ3Zkgv3M2SbJujbXoiIMU209EkTTCYRAYd0cswwI=; b=lM1pjSXQorELA17BPLqjY39F3Zwka8K17mLf5JmgXPd4geA/4WwHKhgfj0TGd7oD8Rup3TvVH7V+i2Pahj1boqwz5rS0mBpshR0ScJH4kfrI9x94shkqGaz/AXPkcwf/v+2Yo6MSC/LWiVwaxG92R6dgNmUUKmAPWBjaqFg6n2w=
Received: from DB5PR05MB1030.eurprd05.prod.outlook.com (10.161.240.149) by DB5PR05MB1032.eurprd05.prod.outlook.com (10.161.240.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 17:22:55 +0000
Received: from DB5PR05MB1030.eurprd05.prod.outlook.com ([fe80::a980:3fb2:8fda:1670]) by DB5PR05MB1030.eurprd05.prod.outlook.com ([fe80::a980:3fb2:8fda:1670%16]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 17:22:55 +0000
From: Nick Chettle <nick@nccnetworks.co.uk>
To: David Schinazi <dschinazi@apple.com>, IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] An Update to Happy Eyeballs
Thread-Index: AQHSmEHPBVnT3qUhpEmVbed86MRKy6GMv+yy
Date: Thu, 09 Mar 2017 17:22:54 +0000
Message-ID: <DB5PR05MB1030F0C8AA7091494BEE0C6C84210@DB5PR05MB1030.eurprd05.prod.outlook.com>
References: <148899860042.20118.391380898590855642.idtracker@ietfa.amsl.com>, <A609BABB-BDF2-4CCB-8452-F489C019748C@apple.com>
In-Reply-To: <A609BABB-BDF2-4CCB-8452-F489C019748C@apple.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: apple.com; dkim=none (message not signed) header.d=none;apple.com; dmarc=none action=none header.from=nccnetworks.co.uk;
x-originating-ip: [25.162.150.4]
x-ms-office365-filtering-correlation-id: bf0205c0-a185-4406-436e-08d46710ec7a
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB5PR05MB1032;
x-microsoft-exchange-diagnostics: 1; DB5PR05MB1032; 7:dTjlwo90vR+B0k6/mYOCjPGVji2NaUBthgpEIQAYrA73Rm05X4RUS1Ueeb0Dx6Mc9leHT8gimhmSQh5WhTVrM5Xa8DcT/UAhUABxZjRrn8E2WlvSt6xTpazNQpK0MZeTM8yRsEJzn3N9im1B9hyd51voNkRoO9PTVNTMoZWMvNYc9U50txeHTUJA1LsCM4PNzxBkcoR72YoJyfnQEK20rHdkNBafBVYfuvSeEQ8ZLzjsJNUx22iD498JR3dd32CGIqksYoRX1c5zXWmlJ7LvgM+bWR3NYxVHgWAbLQDXDPk+Md/l4f1q49E2nSnwGmfzQnVPbFAe5AvQRqwLZvaA0g==
x-microsoft-antispam-prvs: <DB5PR05MB1032B80D979258A775B9F9B284210@DB5PR05MB1032.eurprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(31960201722614);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(2016111802025)(20161123562025)(20161123564025)(20161123558025)(20161123555025)(20161123560025)(6043046)(6072148); SRVR:DB5PR05MB1032; BCL:0; PCL:0; RULEID:; SRVR:DB5PR05MB1032;
x-forefront-prvs: 0241D5F98C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(377424004)(189998001)(3660700001)(76176999)(50986999)(3280700002)(7110500001)(5660300001)(2906002)(54356999)(5250100002)(106116001)(74482002)(33656002)(2900100001)(305945005)(7736002)(74316002)(66066001)(8666007)(6246003)(55016002)(81166006)(99286003)(38730400002)(53936002)(229853002)(53546006)(42882006)(86362001)(3846002)(6436002)(8676002)(9686003)(8936002)(15650500001)(6306002)(7696004)(6116002)(102836003)(2420400007)(6506006)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR05MB1032; H:DB5PR05MB1030.eurprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nccnetworks.co.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 17:22:54.8156 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 56ec107c-cefb-4ecc-a306-77dfc5d215a7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR05MB1032
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ZcU1n_QJv7lmlRHG1taa6DjLl2E>
Subject: Re: [v6ops] An Update to Happy Eyeballs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Mar 2017 17:23:01 -0000

Hi David,

It looks good, thanks for sharing what you've learnt.

I just have one question, when talking about the DNS query in section 2 you say:

Both queries SHOULD be sent on the wire as
   close together as possible, with the ordering being dictated by the
   system's host address preference policy.

Then when talking about DNS server selection in Section 2.1 you mention that:

In keeping with the Happy Eyeballs approach,
   queries SHOULD be sent over IPv6 first.

Are these statements slightly contradictory or should DNS queries relate to the host policy while DNS server selection always uses IPv6 first?

Thanks, Nick





________________________________________
From: v6ops <v6ops-bounces@ietf.org> on behalf of David Schinazi <dschinazi@apple.com>
Sent: 08 March 2017 19:25:29
To: IPv6 Operations
Subject: [v6ops] An Update to Happy Eyeballs

Hi v6ops,

Tommy Pauly and myself have written up what we've learned
in the past few years maintaining and improving Apple's Happy Eyeballs stack,
and submitted it as draft-pauly-v6ops-happy-eyeballs-update.

You'd love to hear your feedback!

Thanks,
David Schinazi


Begin forwarded message:

From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: New Version Notification for draft-pauly-v6ops-happy-eyeballs-update-00.txt
Date: March 8, 2017 at 10:43:20 PST
To: Tommy Pauly <tpauly@apple.com<mailto:tpauly@apple.com>>, David Schinazi <dschinazi@apple.com<mailto:dschinazi@apple.com>>


A new version of I-D, draft-pauly-v6ops-happy-eyeballs-update-00.txt
has been successfully submitted by David Schinazi and posted to the
IETF repository.

Name: draft-pauly-v6ops-happy-eyeballs-update
Revision: 00
Title: An Update to Happy Eyeballs
Document date: 2017-03-08
Group: Individual Submission
Pages: 7
URL:            https://www.ietf.org/internet-drafts/draft-pauly-v6ops-happy-eyeballs-update-00.txt
Status:         https://datatracker.ietf.org/doc/draft-pauly-v6ops-happy-eyeballs-update/
Htmlized:       https://tools.ietf.org/html/draft-pauly-v6ops-happy-eyeballs-update-00


Abstract:
  "Happy Eyeballs" (RFC6555) is the name for a technique of reducing
  user-visible delays on dual-stack hosts.  Since one address family
  (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network,
  clients that attempt connections for both address families in
  parallel have a higher chance of establishing a connection sooner.
  Now that this approach has been deployed at scale and measured for
  several years, the algorithm specification can be refined to improve
  its reliability and generalization.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

v2.23.0 | Report a Bug | By Email