Subject: [arch-d] Centralization or diversity

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Nov 2019 09:58:08 +1100

Having just read draft-arkko-arch-infrastructure-centralisation, I was struck by an observation.

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.

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)

There are probably areas of diversity that are less valuable.  Protocol diversity has the effect of forcing divisions.  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].

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Nov 2019 23:53:58 +0200

Martin,

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

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

> * 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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Nov 2019 23:59:22 +0200

Martin,

Agree here too.

Jari