Why you should care about complexity

If you look across a wide array of networking problems, you will see what is an apparently wide array of dissimilar and unrelated problems engineers deal with on a daily basis. For instance—

• Should I split this flooding domain into multiple parts? If so, where should I divide it?
• Which routing protocol should I use on this network topology, and to solve this set of problems?
• How should I configure the Quality of Service parameters on this network?
• Should I use MPLS on my data center fabric, or straight IP?

Over my years as a network engineer, I’ve always treated these as separate sorts of problems, each with their own tradeoffs, concepts, and models. In fact, I’ve been a kindof “collector of models” over the years, trying to find different models to address each situation. In the Art of Network Architecture, there’s an entire chapter on the models Denise and I have run in to over the years, where they seem to be useful, and where they seem to be limited.

But keeping all of these models in my head didn’t help me generalize the problems I faced in building and troubleshooting networks. For instance, in the flooding domain instance I’ve always used the model of split complexity from complexity as my rule of thumb. For the routing protocol question, I’m always trying to figure out what the “primary” or “most common” topology is, and then just living with the protocol choice for that topology on the rest of the network. For quality of service, we have rules of thumb. For MPLS, it’s just one big argument over what’s simpler and why.

And it’s the last that gives you the clue of how these are all related—complexity. Several years ago at Interop, Dave Meyers did a presentation on complexity. Dave, as it turns out, is more research focused, and I’m more focused on “great, but what can I do with this information?” The presentation stuck in my mind, and I kept finding that I could frame problems like those in the list above in terms of complexity.

At some point, this line of thinking coalesced into a model—not really a model, exactly, but a model of a set of questions to ask and places to look. The model has shifted in focus and content over time (it actually changed over the course of writing a book on this topic, in fact), but there are three components:

• State, both the amount of state and the rate at which it changes
• Surface, or the way adjacent and interconnected systems interact
• Optimization, or the optimal use of network resources and support for applications

This model is useful for analyzing the problems listed above. As an instance, let’s take the last one: should I use MPLS in my data center, or straight IP? From a state perspective, will using MPLS increase the amount of state in the control plane, reduce it, or is it a wash? Each new protocol that needs to be carried over the fabric, and each new traffic engineering problem you face on the fabric, increases the amount of state in the control plane. At some point deploying MPLS either causes the state to be a wash or actually decreases state. From a surface perspective, if you have three or four different tunneling protocols, one for each transport carried over the fabric, you have a lot of moving parts that need to be managed, and that will interact with one another. MPLS can reduce the interaction surfaces by providing a single sub-transport that can carry all the other transports. Looking at optimization uncovers questions about engineering traffic flows and service chaining.

The state/surface/optimization triangle is like the high quality/cheap/done quickly triangle. Moving to one corner of the triangle will always make you move away from the others—it’s just the way it works. If you know where you’re moving, you know what you’re moving away from, and hence you can be a lot more intelligent about the tradeoffs you’re making.

And that’s why you should care about complexity—because it helps you to ask the right questions, choose the right model, and see the tradeoffs for what they really are.

Oh, and the book—did I mention the book? If you really want to dive into this, this book is the place to learn more…