[arch-d] centralization

[Yaakov Stein <[e-mail]>]

> Market consolidation and centralization can be good ...
> But there are also some serious drawbacks.

Yes. There are often trade-offs and these trade-offs can be analyzed.

In response to one remark I pushed into the chat window a remark about the CAP theorem.
This theorem is commonly used when analyzing distributed systems,
and is directly applicable to networks which are distributed systems for delivery of packets.

Basically the CAP theorem says you can't have all three of Consistency, Availability, and Partition (fault) Tolerance.
IETF people are used to distributed routing protocols that emphasize A and P at the expense of C
(which is why we need a TTL field in the packet header),
while computation academics who expect consistency gave us centralized SDN.
For databases the two extremes are called ACID and BASE.

To enable more nuanced trade-offs networks use both control (distributed) and management (centralized) planes,
for example centralized management for policy and distributed control for rerouting.
(So, what SDN does is not to introduce a control plane, but rather to replace the control plane by a management plane.)

However, when referring to multi-user networked applications (not the communications service)
there is strong pressure towards centralization.
Why do we have basically one Facebook, one Amazon, etc?
Because the value of a network application is super linear (Metcalfe's law puts is a N^2, Reid's law puts it at 2^N)
which means that one large network is worth much more than 2 half-sized networks.
Over time this pressure can't be resisted.

Y(J)S