When Metaphors Fail

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.

Weekend Reads 011819

Optimism around 5G may be strong for now, but service providers are finding it difficult to convey a feasible business case for the technology as average consumers remain ill-informed of its true benefits. 61% of respondents were hopeful about the overall availability of 5G coming in the next two years, however, 40% don’t believe consumers will be willing to pay more for the privilege. —Sigal Biran-Nagar

DNS security from the client perspective is a one-hour online course examining both technical and managerial topics associated with the security of the Domain Name System. Participants will learn about the process of a domain name and DNS request, from registration to name resolution; the security risks of each component; and the mitigation options currently available. —Lisa Corness

Your job search can feel like a movie you’ve seen over and over. The same thing seems to happen every time. You get motivated to finally start looking for a new job. You hunt around the internet and make a list of intriguing jobs. You start imagining yourself getting out of your current job. You start applying, there’s progress, you get some call backs, maybe you even go on-site to interview a few times. There’s a ray of hope. Inevitably, though, there’s a barrage of rejections and insecurity creeps in. —DJ Chung

We all know by now that both Apple and Samsung, giants in the smartphone space, have issued sales warnings. What we don’t all know, and what in fact none of us really knows, is what this means to networking both at the service and the infrastructure level. Smartphones are arguably the most significant single devices in tech history, so surely a seismic change in the market would mean something. What? —Tom Nolle

Reaction: Open Source

As long-standing contributor to open standards, and someone trying to become more involved in the open source world (I really need to find an extra ten hours a day!), I am always thinking about these ecosystems, and how the relate to the network engineering world. This article on RedisDB, and in particular this quote, caught my attention—

There’s a longstanding myth in the open-source world that projects are driven by a community of contributors, but in reality, paid developers contribute the bulk of the code in most modern open-source projects, as Puppet founder Luke Kanies explained in our story earlier this year. That money has to come from somewhere.

The point of the article is a lot of companies that support open source projects, like RedisDB, are moving to a more closed source solutions to survive. The cloud providers are called out as a source of a lot of problems in this article, as they consume a lot of open source software, but do not really spend a lot of time or effort in supporting it. Open source, in this situation, becomes a sort of tragedy of the commons, where everyone things someone else is going to do the hard work of making a piece of software viable, so no-one does any of the work. Things are made worse because the open source version of the software is often “good enough” to solve 80% of the problems users need solved, so there is little incentive to purchase anything from the companies that do the bulk of the work in the community.

In some ways this problem relates directly to the concept of disaggregated networking. Of course, as I have said many times before, disaggregation is not directly tied to open source, nor even open standards. Disaggregation is simply seeing the hardware and software as two different things. Open source, in the disaggregated world, provides a set of tools the operator can use as a base for customization in those areas where customization makes sense. Hence open source and commercial solutions compliment one another, rather than one replacing the other.

All that said, how can the open source community continue to thrive if some parts of the market take without giving back? Simply put, it cannot. There are ways, however, of organizing open source projects which encourage participation in the community, even among corporate interests. FR Routing is an example of a project I think is well organized to encourage community participation.

There are two key points to the way FR Routing is organized that I think is helpful in controlling the tragedy of the commons. First, there is not just one company in the world commercializing FR Routing. Rather, there are many different companies using FR Routing, either by shipping it in a commercial product, or by using it internally to build a network (and the network is then sold as a service to the customers of the company). Not every user of FR Routing is using only this one routing stack in their products or networks, either. This first point means there is a lot of participation from different companies that have an interest in seeing the project succeed.

Second, the way FR Routing is structured, no single company can gain control of the entire community. This allows healthy debate on features, code structure, and other issues within the community. There are people involved who supply routing expertise, others who supply deployment expertise, and a large group of coders, as well.

One thing I think the open source world does too often is to tie a single project to a single company, and that company’s support. Linux thrives because there are many different commercial and noncommercial organizations supporting the kernel and different packages that ride on top of the kernel. FR Routing is thriving for the same reason.

Yes, companies need to do better at supporting open source in their realm, not only for their own good, but for the good of the community. Yes, open source plays a vital role in the networking community. I would even argue closed source companies need to learn to work better with open source options in their area of expertise to provide their customers with a wider range of options. This will ultimately only accrue to the good of the companies that take this challenge on, and figure out how to make it work.

On the other side of things, open source is probably not going to solve all the problems in the networking, or any other, industry in the future. And the open source community needs to learn how to build structures around these projects that are both more independent, and more sustainable, over the long run.

The only thing constant is change

Several things of note for the near future.

As of today, I have moved into a role at Juniper networks. You will probably hear more about what I am working on over time, both here and there, and probably other places as well.

I hope to be changing platforms from WordPress to Craft in the spring; work is currently underway. This will likely mean some things about the design of this site will change; others will remain the same. Content wise, I am going to continue highlighting interesting research, soft skills, and networking technologies, but I will be trying to focus a bit more on disaggregation in all of these areas, rather than just floating around all over the place.

More as 2019 develops.

Weekend Reads 011119

Just when you express hope that the network industry can shed the past, somebody demonstrates it won’t be easy. An interview in Light Reading with Amdocs CTO Anthony Goonetilleke proposes that one of the unsung benefits of 5G is that it will enable operators to charge for services rather than for data. Is this really a 5G revolution in making, or are we simply reprising the same kind of silly stuff that’s been around for decades? —Tom Nolle

The Silicon Valley gospel of “disruption” has descended into caricature, but, at its core, there are some sound tactics buried beneath the self-serving bullshit. A lot of our systems and institutions are corrupt, bloated, and infested with cream-skimming rentiers who add nothing and take so much. —Cory Doctorow

The high-order bit in much of the below is complexity. Hardware, software, platforms, and ecosystems are often way too complex, and a whole lot of our security, privacy, and abuse problems stem from that. —Chris Palmer

How much of the internet is fake? Studies generally suggest that, year after year, less than 60 percent of web traffic is human; some years, according to some researchers, a healthy majority of it is bot. For a period of time in 2013, the Times reported this year, a full half of YouTube traffic was “bots masquerading as people,” a portion so high that employees feared an inflection point after which YouTube’s systems for detecting fraudulent traffic would begin to regard bot traffic as real and human traffic as fake. They called this hypothetical event “the Inversion.” —Max Read

Early numbers indicate that 2018 was a relatively quiet year in terms of huge distributed denial-of-service (DDoS) attacks, but does that indicate quieter times ahead in 2019? While it’s tricky to predict the future in cybersecurity, some experts think that improvements in DNS security are forcing criminals and vandals to change their strategies in order to keep up. —Curtis Franklin, Jr.

The Intel CPU is continuing to shrink, and Ice Lake is promising to bring computing down to a 10nm production node this holiday season. The processor promises to include the typical improvements we see with every generation including better battery performance and faster graphics, but it has a few tricks up its sleeves. —Michael Archambault

No one doubts that artificial intelligence (AI) and machine learning (ML) will transform cybersecurity. We just don’t know how, or when. While the literature generally focuses on the different uses of AI by attackers and defenders ­ and the resultant arms race between the two ­ I want to talk about software vulnerabilities. —Bruce Schneier

It is difficult these days to avoid hearing about blockchain. Blockchain is going to be the foundation of a new business world based on smart contracts. It is going to allow everyone to trace the provenance of their food, the parts in the items they buy, or the ideas that they hear. It will change the way we work, the way the economy runs, and the way we live in general. —Jim Waldo

Yesterday Bloomberg reported that the scandal-beset social media behemoth has inked an unknown number of agreements with Android smartphone makers, mobile carriers and OSes around the world to not only pre-load Facebook’s eponymous app on hardware but render the software undeleteable; a permanent feature of your device, whether you like how the company’s app can track your every move and digital action or not. —Natasha Lomas