21 years and counting of 'eight fallacies of distributed computing' | APNIC Blog

Skip to content

Skip to the article

Image by Gerd Altmann from Pixabay.

You’d think that by now, networks were well enough understood that people would stop making assumptions that we have known, almost since the dawn of networking, to be untrue. Yet as users, developers, and network administrators, we still seem curiously unable to let go of long-held beliefs.

Perhaps the best-known collection of mistaken ideas about networks is the eight fallacies of distributed computing.

The eight fallacies

The network is reliable

Latency is zero

Bandwidth is infinite

The network is secure

Topology doesn’t change

There is one administrator

Transport cost is zero

The network is homogeneous

Where did this list come from?

The list began with four original fallacies (the first four in the list), collected by Bill Joy and Tom Lyon, two of the original eight founders and employees of Sun Microsystems.

Sun integrated high-speed graphics, the UNIX operating system, and a working Internet protocol stack, which led to the explosion in desktop computing, their meteoric rise, and ultimate acquisition by Oracle Computing. When you use a Berkeley Software Distribution (BSD) variant, a Linux distribution, or even Android, you’re using technology that has followed a lineage from Sun Microsystems. Think of the ZFS file system, the Network File System (NFS) protocol for network file storage, and Java, to name a few.

The list was later expanded by L. Peter Deutsch, who added a further three fallacies while at Sun. The final fallacy was coined by James Gosling, who, fittingly, also worked at Sun, bringing us to the eight fallacies we now know and love.

Over time, these ideas have settled and inspired other lists of fallacies — for example, the fallacies surrounding dates and times, or the falsehoods people believe about names. I would be surprised if there weren’t more. We encounter these date and name errors constantly, whether filling in forms or interacting with assets on the web or in apps.

The underlying eight fallacies of distributed computing are buried ‘constants’ in our use of the network. They are worth thinking about as network operators, whether in protocol and software design, or how they impact users in daily life. By keeping them in mind, we can better address the behaviours that arise from these fallacies as we encounter them online.

The list is aimed at people writing network software: Applications that call into the network, services that are called from the network, and network protocols. It provides practical guidance — even if presented abstractly — on how to think about sending data through a network, and the questions you should ask. Questions such as:

Was it actually sent?

Was it received?

How can you tell?

Can you send it again, or is the data gone?

Does it even need to be sent again?

Do you have time to handle this data? How will it affect the rest of your program?

Does the network behave in ways you really understand, despite its complexity??

Looking at the fallacies case by case

What follows is my personal understanding of the meaning of each of the eight fallacies of distributed computing, as they relate to how the network behaves towards me and my services. Others have different views, and I may have gotten some things wrong.

Figure 1 — The eight fallacies of distributed computing.

1. The network is reliable

Measured as a whole, the Internet is probably broken somewhere, for some users, at all times. That we individually experience it as reliably available is a triumph of hope over experience. Claims of ‘five nines’ reliability often lead us to act as if ‘it won’t happen to me’.

More specifically, people tend to assume that once a packet is sent, it will be received. Most of the time, it is. But we still have to design protocols to handle the cases when it isn’t.

Consider the first of the three classic measures of a network’s behaviour: loss, delay, and jitter. ‘Loss’ is simply another way of saying ‘unreliable’. If your protocol doesn’t account for the fact that data can be lost, it will run into problems. Much of the Transport Control Protocol (TCP) and QUIC layers are specifically designed to recognise packet loss and handle it.

Internet Protocol (IP) — whether version four or six — does not guarantee delivery. That responsibility falls to higher layers if they are capable.

2. Latency is zero

Latency encompasses the other two network issues mentioned above: Delay and jitter. Delay is sometimes simply a function of distance, given the speed of light — but even this can be misunderstood, since the speed of light in fibre is slower than in a vacuum.

Additional delays occur when converting a signal from copper to fibre and sending it along a fibre optic link. Because of this, sending data via microwave, radio, or even laser between satellites can sometimes be faster than sending it through...