Raw capture â raw/21-years-eight-fallacies-distributed-computing.md
url: https://blog.apnic.net/2025/12/08/21-years-and-counting-of-eight-fallacies-of-distributed-computing/ date_fetched: 2026-07-05 backfilled: true
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 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:
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.
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.
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 fibre.
Jitter, the variability of delay, is a major challenge for gaming and streaming protocols. Latency and loss are the reasons why services like Netflix both buffer data and use error-correcting codes. These techniques compensate for fluctuations in delay, providing a smooth and reliable playback experience.
Itâs tempting to think that in the modern Internet, we can sometimes treat bandwidth as effectively infinite for most practical purposes. The reality, however, is that many links in the system have more people sending packets than there are spaces available to carry them.
Dealing with the consequences of âless-than-infiniteâ bandwidth introduces queuing, which in turn creates delay. With delay comes jitter, and under extreme conditions, packet loss. The limitations of finite bandwidth directly affect every network flow subject to these constraints.
In todayâs network, where data is often âclose byâ in a Content Delivery Network (CDN), we rarely notice this. In bandwidth terms, the limits of the network are often far removed from us â with one exception: our local home link.
We may use gigabit-capable devices, but our local link speed is often only a few hundred megabits. Can we exceed our home routerâs capacity? Almost trivially. Can we exceed our home Wi-Fi network? Certainly. A modern mobile phone can sustain 400 Mbit/sec or more, but a Wi-Fi network purchased five years ago might cap out at 100 Mbit/sec.
Investing in network bandwidth to match expectations is like building roads to handle peak-hour traffic: you can make it appear that congestion doesnât exist, but the cost may be higher than desired. When upgrading a home router to match the speed of new edge fibre delivery, we face the same question: how much bandwidth do we really need?
In the days of monopoly telecommunications, when a single provider ran networks across an entire economy, there was one major risk: that the provider might fail to ensure the privacy of our data. Typically, they controlled all the infrastructure, and intrusions were rare, if not unheard of. Encoding overhead was minimal, and law enforcement could access data through a single channel.
Today, networks run across multiple providers and through intermediaries with whom we have no relationship. Continuing to believe that nobody is âseeingâ our packets is naĂŻve. What we can do is ensure the packets themselves contain only secret, protected data. Designing protocols to provide this protection â now and into the future â is both costly and time-consuming. With emerging quantum computing threats to publicâprivate key cryptography, even this protection may not be as guaranteed as we would like.
Even protected packets, however, reveal information. Traffic analysis can expose patterns, and advanced machine learning can distinguish streaming, file storage, and interactive traffic from packet timing and size alone. Never treat the network as inherently secure, and never rely on it below your HTTPS or Transport Layer Security (TLS) connections to hide you from others.
Topology changes can come from many sources. They occur when your mobile phone connects to a different tower, or when the phone of the person you are communicating with does. They also occur when your provider optimises traffic for efficiency or profit by routing packets differently than you expect. We experience these topology changes as loss, delay, and jitter.
Transport protocols like QUIC and TCP shield us from the effects of changes âin the middleâ of the network and the resulting impact on packet paths from source to destination. However, the processes that manage these changes â such as Virtual Router Redundancy Protocol (VRRP), Common Address Redundancy Protocol (CARP), Border Gateway Protocol (BGP), or Multipath TCP â are not free. These overheads mean that assumptions such as no loss, no delay, or no duplication of data cannot be relied upon.
Sometimes, it feels as if there isnât even a single administrator. Other times, it seems like having just one would be better than the many we encounter. Even within a single Network Operations Centre (NOC), multiple hands, models, and processes can be at work. Modern networks are so complex that the administrator you speak to is very probably not the one actually making changes in the system.
Cost is multidimensional. Take the Short Message Service (SMS) protocol as an example. If you multiplied the cost of sending a few packets via SMS by the number of packets required to send a movie, the total would run into thousands of dollars. But does that reflect the actual cost?
Where does cost come from in a network? Is it the electricity needed to transmit packets? The hardware? The support systems, business logic, accounting, and risk management? All of these contribute real-world costs to make data transport possible. Just because cost is not exposed directly in a protocol does not mean it doesnât exist â it means that the cost is being absorbed elsewhere in society.
Some costs are never recovered directly and simply become part of the aggregate âcost of doing businessâ. Others, such as the asymmetric charges for sending and retrieving data from Amazon S3 long-term storage, are deliberately structured to encourage fetching data only when necessary.
One of the great fallacies of BGP routing is the idea that âcostâ is the same as AS path length. If you ignore all other factors, you might prefer the route with the fewest AS hops. But is that really wise?
Consider connecting European nodes to Asian nodes over a slow, expensive, low-capacity link, while exposing all your European peers to your Asian peers. That thin, costly link will quickly become congested. The inconsistencies in delay, bandwidth, and load capacity become apparent almost immediately.
Even in simple home networks, differences between devices on Wi-Fi and devices on Ethernet can be stark. A TV streaming over Wi-Fi competes for airtime with other devices on the same channel, a problem that doesnât exist when using an Ethernet switch.
The costs of delay and retransmission are largely hidden by oversupply, buffering, and encoding. Yet, if you examine network behaviour closely, the differences are clear. IP) masks many of the nuances between local and remote, slow and fast, or reliable and unreliable connections. Higher-layer protocols, however, must handle these realities â balancing time, buffer usage, and computational costs â to deliver the best service possible under the circumstances.
The network wouldnât be what we know and love if the list of network fallacies didnât contain a fallacy itself. Several online discussions of these fallacies mistakenly refer to Tom Lyon as Dave Lyon. It seems that, over time, even facts canât be counted on to remain fixed.
Maybe one day this list of eight fallacies will grow to nine or ten. I think itâs unlikely to drop down to seven.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.