We often use metaphors to describe a particular part of a thing or the thing itself. For instance, we might say “I’m as hungry as a horse,” to describe how much we think we could eat (although a more appropriate saying might be “as hungry as a bird,” as it turns out!). Network operators and engineers are no exception to this making of metaphors, of course.

Metaphors have a reductionistic tendency. For instance, when saying I am as hungry as a horse, I am relating the amount of food a horse might eat to the amount of food I feel like eating. The metaphor reduces the entire person and the entire horse so the turn on a single point—a quantity of food. In using this kind of comparison, I am not claiming to have the same number of legs as a horse, or perhaps a swishing tail like a horse.

The danger in using a metaphor is that you can take the part to be the whole. When this happens, the metaphor says things it should not say, and can cause us to misunderstand the scope, complexity, or solution to a problem. For some reason, we tend to do this a lot in networking—let’s look at a few examples.

Networks are just plumbing. I have, on occasion, used this very metaphor—and it is very common in the industry. But is this really right? If each packet is a drop of water, then the order in which drops of water are delivered, how long it takes to deliver them, and the jitter in the delivery rate should matter. I’ve never seen a water delivery system where the order in which individual drops of water are delivered matters. There are classes of water, of course—recycled, filtered, spring, tap, waste, etc.—but these are generally handled by different systems within a building. For instance, spring water would normally be delivered in a container, waste water is carried away in one piping system, and tap water is carried from some outside source through a separate system of pipes.

Networks are not like plumbing because while water is a commodity—each drop of water within a given class of water is entirely identical, and each class of water is carried in a separate physical system—packets are not (really) a commodity. There are hundreds, potentially thousands, of kinds of packets in a network, each kind of which may have different requirements, and all of which must be carried over a single physical infrastructure.

Of course, water systems are much more complex than the pipes in a single house—something we don’t tend to think about when using this metaphor. There are wells, treatment plants, wastewater plants, local filtering system, water softeners, and many other related systems. If I were to compare a network to anything in plumbing, it would be closer to an entire water system, rather than the plumbing in a single house—and even then, the complexity is of a different kind.

Networks are like memory. Just like I can add more memory to a computer, I should be able to add more bandwidth to a network. There are three problems with this metaphor. First, memory is attached to a local network (often called a “bus”), and generally dedicated to the use of a well-defined set of processors. Networks are not like this at all; a network is a resource shred among potentially hundreds of thousands of computers. The scope of resource sharing is of a completely different kind. Second, memory, and the network it uses to connect to the processor, is normally constrained within fairly narrow physical boundaries. Networks, on the other hand, are distributed systems. Third, each bit of memory is (within some bounds) identical with every other bit of memory. There are, perhaps, two or three classes of memory within a computer, but not hundreds or thousands. The packets carried by a network are not this way; each flow of packets can represent unique challenges to the network.

Again, then, networks are not “just like memory.” Adding bandwidth, and scaling a network, will likely never be the same kind of thing as adding memory to a single computer.

Networks are like cars. This one is fairly common, as well; you get in your car, and you drive it from point A to point B. You throw stuff in the back if you need, which is the payload of the packet. Operating the network should be as simple as operating a car.

But are networks really this way? Is there a single size of packet that will transport every kind of data? Or are packets more like vehicles in a larger sense—there are trucks to carry large and heavy loads, and sports cars to carry small, fast, loads. In between there might be vans, light trucks, etc. In fact, extending the metaphor might make sense; there are trains that carry synchronous flows of payload, and there are trucks and cars that carry asynchronous payloads. There are ships that carry large of information slowly over long distances, and airplanes that carry moderate amounts of information more quickly. Each of these might have different kinds of physical layers, and each kind of traffic and physical layer has its own policies and ways of enforcing these policies.

If I were to relate networks to anything in the transportation world, it would be an entire transportation system, including roads, traffic signals, railroads, sea lanes, air lanes, and the vehicles that run on all these things.

Metaphors like these are useful, of course, in helping us see one part of the problem that needs to be solved and bringing an idea to a scale we can understand. But when we reduce the network to one of these things is to risk making a problem more complex or simpler than it really is.

Be careful with your metaphors—they can mislead and obscure just as easily as enlighten.