Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis

Mark Andrews <marka@isc.org> Tue, 05 November 2013 20:26 UTC

Return-Path: <marka@isc.org>
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 5256E11E8196 for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 12:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.21
X-Spam-Level:
X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP80zs-BbPph for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 12:26:10 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 0875011E813A for <v6ops@ietf.org>; Tue, 5 Nov 2013 12:26:01 -0800 (PST)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 7AE4BC948E; Tue, 5 Nov 2013 20:25:46 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1383683159; bh=SxXL31POFNJLqQ8Xe0y+DDWrOiclXmaJB1AekYLkOjQ=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=AYTIMOWqySTmgkWLaIi+pckycGpOxKi5/QMkbMKaB3u/wgIvZPUCPJCF89vbE0Gbx UOW23j7IWKJ2r2OiD95sOY5lv+p70+sbBvflwoLgNloTA6Mx96tm8gN9PyWbOEl4Zi 9sUpDCNJShUNW0WzV0ec2mObMotIxTpZrFkXNeBI=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 5 Nov 2013 20:25:46 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8669A1603E9; Tue, 5 Nov 2013 20:31:30 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 51A01160363; Tue, 5 Nov 2013 20:31:30 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 03603992E6A; Wed, 6 Nov 2013 07:25:43 +1100 (EST)
To: Lorenzo Colitti <lorenzo@google.com>
From: Mark Andrews <marka@isc.org>
References: <a2dc12c28a1d4eb28e7da36c959e2e9b@BN1PR03MB171.namprd03.prod.outlook.com> <F5022E7E-5969-4961-8C1F-03A8FD6C8069@ecs.soton.ac.uk> <EMEW3|c7700e679335ec63fa8cc5ca34b52656pA42wx03tjc|ecs.soton.ac.uk|F5022E7E-5969-4961-8C1F-03A8FD6C8069@ecs.soton.ac.uk> <fbfd317f606e47fb8666f45cfe8ce7df@BN1PR03MB171.namprd03.prod.outlook.com> <1383679978.91401.YahooMailNeo@web142501.mail.bf1.yahoo.com> <CAKD1Yr1qqTDdzAcmhUL=dA86DG=HyjDU=552FPPZM7UPPSdbuA@mail.gmail.com>
In-reply-to: Your message of "Wed, 06 Nov 2013 04:37:21 +0900." <CAKD1Yr1qqTDdzAcmhUL=dA86DG=HyjDU=552FPPZM7UPPSdbuA@mail.gmail.com>
Date: Wed, 06 Nov 2013 07:25:43 +1100
Message-Id: <20131105202544.03603992E6A@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] ULA and IPv4 - draft-liu-v6ops-ula-usage-analysis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 05 Nov 2013 20:26:18 -0000

In message <CAKD1Yr1qqTDdzAcmhUL=dA86DG=HyjDU=552FPPZM7UPPSdbuA@mail.gmail.com>
, Lorenzo Colitti writes:
> On Wed, Nov 6, 2013 at 4:32 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au>wro
> te:
> 
> > Happier Eyeballs
> > http://tools.ietf.org/html/draft-baker-happier-eyeballs-00.html
> 
> 
> Great. We can't be bothered to get things right in the network, so we just
> tell hosts to try everything all the time in the hope that something will
> work.

While devices should return unreachables we all know that there are
error conditions where that does not happen even when they are
configured to do so.  If you have multihomed servers then the clients
should be failing over faster than they tradionally have.  We spend
BILLIONS dealing with clients that do not fall over fast enough.

> It's very easy to say "we should just have smarter algorithms", especially
> if we expect that someone other than ourselves will be writing those
> algorithms, but I have yet to see a proposal that's sanely implementable,
> high performance, and low load (even considering the fact that you'd have
> to completely overhaul the socket API and app the apps using it before you
> could deploy it).

You can have fast failover using the current socket APIs.  For TCP
is is relatively trivial, just use a non-blocking connect call.
For UDP it is a little harder but not impossible.  DNS servers have
been dealing with multihomed services for decades.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org