Systems Approach Anyone who studies internet technology quickly learns about the importance of distributed algorithms to its design and operation. Routing protocols are an obvious example of such algorithms.
I remember learning how link-state routing worked and appreciating the elegance of the approach: each router telling its neighbors about its local view of the network; flooding of these updates until each router has a complete picture of the network topology; and then every router running the same shortest-path algorithm to ensure (mostly) loop-free routing. I think it was this elegance, and the mental challenge of understanding how such algorithms work, that turned me into a “networking person” for the next thirty years.
The idea of decentralization is baked quite firmly into the internet’s architecture. The definitive paper on the internet’s original design is David Clark’s “The Design Philosophy of the DARPA Internet Protocols” published [PDF] in 1988. Near the top of the list of design goals we find “Internet communication must continue despite loss of networks or gateways,” and “The Internet must permit distributed management of its resources.” The first goal leads directly to the idea that there must not be single points of failure, while the second says more about how network operations must be decentralized.
When I worked on the team developing MPLS in the late 1990s, we absolutely believed that every algorithm had to be fully decentralized. Both MPLS traffic engineering (TE) and MPLS-BGP VPNs were designed to use fully distributed algorithms with no central point of control. In the case of TE, we realized early on that centralized algorithms could come closer to providing optimal solutions, but we couldn’t see any way to get those algorithms into the hands of users, given the fundamentally distributed nature of routing.