Re: [arch-d] Centralization or diversity

Jari Arkko <> Wed, 13 November 2019 21:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62F26120809 for <>; Wed, 13 Nov 2019 13:56:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dhhYRgYvPuat for <>; Wed, 13 Nov 2019 13:56:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F38AB1200DB for <>; Wed, 13 Nov 2019 13:56:01 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DFE066012D; Wed, 13 Nov 2019 23:56:00 +0200 (EET)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x1GdwTtLXXRJ; Wed, 13 Nov 2019 23:55:59 +0200 (EET)
Received: from [] ( [IPv6:2001:14b8:1829::130]) by (Postfix) with ESMTPS id 050666600DF; Wed, 13 Nov 2019 23:55:59 +0200 (EET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jari Arkko <>
In-Reply-To: <>
Date: Wed, 13 Nov 2019 23:53:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [arch-d] Centralization or diversity
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Nov 2019 21:56:04 -0000


Thanks for your read and thoughts. Inline:

> The draft specifically calls out the notion of a single point of failure being a problem.  But my experience with centralized services is that they aren't centralized in the fault tolerance sense.  If I look at the big services, that scale is only achieved with careful distributed systems design.  Name any modern service of even modest scale and you generally find excellent fault tolerance.

As Andrew points out, the draft indeed notes that even on a technical side there are issues that can cause a distributed system to fail, e.g. management systems failing. So yes, we have learned to build distributed systems quite well, but it does not remove all causes of errors in those systems. History of failures even in large systems tends to support this notion...

> This draft really wants to say something less negative: that it values diversity on multiple axes.  The draft covers:
> * fault domains
> * geopolitical
> * organizational
> To which I might add:
> * geographic
> * implementation
> * infrastructure (power, network, hardware)

Here I agree with you. That’s a good formulation; there needs to be diversity along several axis.

> There are probably areas of diversity that are less valuable.  Protocol diversity has the effect of forcing divisions.

Agree here too.

> I tend to think that cryptographic diversity divides the limited resources available for protecting and assuring system integrity.  And diversifying where standardization happens is almost certainly bad [RFC5704].

Agree on standards; not sure about cryptographic diversity though. 

> Finally, I don't like the emphasis on DNS in this document.  It only serves to sensationalize.

Your preference is noted :-) My personal opinion is that what’s happening to the DNS is an important topic. The various trends and changes are topics that the Internet community *should* have discussions about. In particular, there are different potential approaches to improving privacy security of DNS with the help of DOH, with very different implications for people’s privacy. There’s potential here for much bigger improvements as well as downsides than for most other current technology changes in the Internet. I think it would be prudent of us to evaluate them carefully, and raise issues where we see them. In my mind, that’s the only way we can improve.