Re: [arch-d] Centralization or diversity

Jari Arkko <jari.arkko@piuha.net> Wed, 13 November 2019 21:59 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3FB120809 for <architecture-discuss@ietfa.amsl.com>; Wed, 13 Nov 2019 13:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVhpeW7i_6ML for <architecture-discuss@ietfa.amsl.com>; Wed, 13 Nov 2019 13:59:27 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id CD1891200DB for <architecture-discuss@ietf.org>; Wed, 13 Nov 2019 13:59:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 01AA866012D; Wed, 13 Nov 2019 23:59:25 +0200 (EET)
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXlM6Yf9IFL7; Wed, 13 Nov 2019 23:59:22 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id D99BF6600DF; Wed, 13 Nov 2019 23:59:22 +0200 (EET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <3db77634-6edf-4047-b758-f83a462420b7@www.fastmail.com>
Date: Wed, 13 Nov 2019 23:59:22 +0200
Cc: architecture-discuss@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E8CB681-8B0A-42D2-9594-57C4C622E602@piuha.net>
References: <3db77634-6edf-4047-b758-f83a462420b7@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/uOu4IGSnHO5ylo6yu_U3dTAyEdc>
Subject: Re: [arch-d] Centralization or diversity
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Nov 2019 21:59:29 -0000

Martin,

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.

Jari