Network Complexity
Can we measure network complexity? Wikipedia states that network complexity is “the number of nodes and alternative paths that exist within a computer network, as well as the variety of communication media, communications equipment, protocols, and hardware and software platforms found in the network.
Wikipedia also defines a complex network as “an enterprise-wide network that uses multiple communication media and communication protocols to interconnect geographically distributed hardware and software platforms would be classified as complex network.”
“A Framework for Measuring Network Complexity”, an Internet Draft written by A. Retana and R. White, addresses this topic, and if you’re interested, you can read the full article on the IETF website. In this blog post I would like to summarize its content for our readers, as I found it very interesting for network engineers.
According to the authors, network complexity is a systemic problem, rather than a component level one.
How to Measure Network Complexity
The authors identified five aspects that affect network complexity and that should be considered when designing an enterprise network:
Control plane state versus optimal forwarding path.
The control plane state is the amount of information carried through the control plane by each device to make a forwarding decision. The more the information in the control plane, the more the complexity, with a negative impact on monitoring, managing and troubleshooting the network. At the same time, removing information from the control plane results in decreased optimality in the path selection, a situation that is termed “stretch” by the authors.
Configuration state versus failure domain separation.
It is common practice in large network environments to create failure domains with the purpose of limiting the number of devices affected by a change or reconfiguration in the network topology. As Retana and White state, large failure domains have the negative impact of cascading failures (think about the impact of STP recomputations or OSPF reconvergence). On the other hand, having too many, smaller, failure domains increases the configuration complexity and, consequently, the chance of human errors. A tradeoff has to be made between number of failure domains and the configuration complexity during the design phase of a network.
Policy centralization versus optimal policy application.
When configuring Quality of Service (QoS) two actions are needed as part of the process: marking and Per Hop Behaviors (PHB). Marking should be configured at the edge of the network, while PHB should be applied to the inner layer of the network so that each network device handles each packet according to its marking. Moving marking closer to the core means configuring a smaller number of devices but packets will not receive proper handling throughout their transmission across the network. This choice does not optimize packet forwarding.
Configuration state versus per hop forwarding optimization.
This aspect goes along with the previous one in terms of complexity. To provide optimal traffic prioritization the traffic classification has to be granular by creating multiple queues or types of service. However such granularity requires extra configuration and increases in network complexity.
Reactivity versus Stability.
This point refers to the speed that the control plane reacts to a change in the configuration or topology. The control plane convergence process can be broken down into four different parts: change detection, propagation of the information about the change, calculation of the optimal path after the change, and establishing the new forwarding path at each hop. The techniques and algorithms implemented to control how fast this information flows through the control plane have added additional complexity in managing the propagation rate.
Main Takeaways about Network Complexity
During the network design process, the network architect has to go through a tradeoff process and find the balance between complexity and optimization. As Retana and White state, “modifying the network to resolve one particular problem will add complexity which results in the increased likelihood of another class of problems.”
At the end of the day, network engineers will be dealing with a certain degree of complexity. The important thing to think about is whether there’s a business case for the complexity introduced as it impacts the overall IT operations of the enterprise, including the number of skilled engineers required to support the network infrastructure.
