| Network Working Group | M. Behringer |
| Internet-Draft | A. Retana |
| Intended status: Informational | Cisco Systems |
| Expires: October 27, 2016 | R. White |
| Ericsson | |
| G. Huston | |
| APNIC | |
| April 25, 2016 |
A Framework for Defining Network Complexity
draft-behringer-ncrg-complexity-framework-02
Complexity is a widely used parameter in network design, yet there is no generally accepted definition of the term. Complexity metrics exist in a wide range of research papers, but most of these address only a particular aspect of a network, for example the complexity of a graph or software. While it may be impossible to define a metric for overall network complexity, there is a desire to better understand the complexity of a network as a whole, as deployed today to provide Internet services. This document provides a framework to guide research on the topic of network complexity, as well as some practical examples for trade-offs in networking.
This document summarizes the work of the IRTF's Network Complexity Research Group (NCRG) at the time of its closure. It does not present final results, but a snapshot of an ongoing activity, as a basis for future work.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 27, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Network design can be described as the art of finding the simplest solution to solve a given problem. Complexity is thus assumed in the design process; engineers do not ask, "should there be complexity here," but rather, "how much complexity is required to solve this problem." This question, "how much complexity," assumes there is some way to characterize the amount of complexity present in a system. The reality is, however, this is an area of research and experience, rather than a solved problem within the network engineering space. Today’s design decisions are made based on a rough estimation of the network’s complexity, rather than a solid understanding.
The document begins with general considerations, including some foundational definitions and concepts. It then provides some examples for trade-offs that network engineers regularly make when designing a network. This section serves to demonstrate that there is no single answer to complexity; rather it is a managed trade-off between many parameters. After this, this document provides a set of parameters engineers should consider when attempting to either measure complexity or build a framework around it. This list makes no claim to be complete, but it serves as a guide of known existing areas of investigation, as well as a pointer to areas that still need to be investigated.
Two purposes are served here. The first is to guide researchers working in the area of complexity in their work. The more researchers are able to connect their work to the concerns of network designers, the more useful their research will become. This document may also guide research into areas not considered before. The second is to help network engineers to build a better understanding of where complexity might be "hiding" in their networks, and to be more fully aware of how complexity interacts with design and deployment.
The goal of the IRTF Network Complexity Research Group (NCRG) [ncrg] was to define a framework for network complexity research, while recognising that it may be impossible to define metrics for overall network complexity. This document summarizes the work of this group at the time of its closure in 2014. It does not present final results, but a snapshot of an ongoing activity, as a basis for future work.
Many references to existing research in the area of network complexity are listed on the Network Complexity Wiki [wiki]. This wiki also contains background information on previous meetings on the subject, previous research, etc.
While there is no generally accepted definition of network complexity, there is some understanding of the behavior of a complex network. It has some or all of the following properties:
The two terms "complex" and "complicted" are often used interchangably, yet they describe different but overlapping properties. The RG made the following statements about the two terms, but they would need further refinement to be considered formal definitions:
Networks typically follow the "robust yet fragile" paradigm: They are designed to be robust against a set of failures, yet they are very vulnerable to other failures. Doyle [Doyle] explains the concept with an example: The Internet is robust against single component failure, but fragile to targeted attacks. The "robust yet fragile" property also touches on the fact that all network designs are necessarily making trade-offs between different design goals. The simplest one is articulated in "The Twelve Networking Truths" RFC1925 [RFC1925]: "Good, Fast, Cheap: Pick any two (you can't have all three)." In real network design, trade-offs between many aspects have to be made, including, for example, issues of scope, time and cost in the network cycle of planning, design, implementation and management of a network platform. Parameters are discussed in Section 4, and Section 3 gives some examples of tradeoffs.
Complex tasks on a network can be done in different components of the network. For example, routing can be controlled by central algorithms, and the result distributed (e.g., OpenFlow model); the routing algorithm can also run completely distributed (e.g., routing protocols such as OSPF or ISIS), or a human operator could calculate routing tables and statically configure routing. Behringer [Behringer] defines these three axes of complexity as a "complexity cube" with three axes: Network elements, central systems, and human operators. Any function can be implemented in any of these three axes, and this choice likely has an impact on the overall complexity of the system.
When discussing network complexity, a large number of influencing factors have to be taken into account to arrive at a full picture, for example:
Networks differ in terms of their intended purpose (such as is found in differences between enterprise and public carriage network platforms, and in their intended role (such as is found in the differences between so-called "access" networks and "core" transit networks). The differences in terms of role and purpose can often lead to differences in the tolerance for, and even the metrics of, complexity within such different network scenarios. This is not necessarily a space where a single methodology for measuring complexity, and defining a single threshold value of acceptability of complexity, is appropriate.
Many changes in a network are made with a dependency on the existing network. Often, a suboptimal decision is made because the optimal decision is hard or impossible to realise at the time. Over time, the number of suboptimal changes in themselves cause significant complexity, which would not have been there had the optimal solution been implemented.
The term "technical debt" refers to the accumulated complexity of sub-optimal changes over time. As with financial debt, the idea is that also technical debt must be repaid one day by cleaning up the network or software.
In considering the larger space of applications, transport services, network services and media services, it is feasible to engineer responses for certain types of desired applications responses in many different ways, and involving different layers of the so-called network protocol stack. For example, Quality of Service could be engineered at any of these layers, or even in a number of combinations of different layers.
Considerations of complexity arise when mutually incompatible measures are used in combination (such as error detection and retransmission at the media layer in conjunction with the use TCP transport protocol), or when assumptions used in one layer are violated by another layer. This results in surprising outcomes that may result in complex interactions, for example oscillation because different layers use different timers for retransmission. These issues have led to the perspective that increased layering frequently increases complexity [RFC3439].
While this research work is focussed network complexity, the interactions of the network with the end-to-end transport protocols, application layer protocols and media properties are relevant considerations here.
Network complexity is a system level, rather than component level, problem; overall system complexity may be more than the sum of the complexity of the individual pieces.
There are two basic ways in which system level problems might be addressed: interfaces and continuums. In addressing a system level problem through interfaces, we seek to treat each piece of the system as a "black box," and develop a complete understanding of the interfaces between these black boxes. In addressing a system level problem as a continuum, we seek to understand the impact of a single change or element to the entire system as a set of tradeoffs.
While network complexity can profitably be approached from either of these perspectives, in this document we have chosen to approach the system level impact of network complexity from the perspective of continuums of tradeoffs. In theory, modifying the network to resolve one particular problem (or class of problems) will add complexity which results in the increased likelihood (or appearance) of another class of problems. Discovering these continuums of tradeoffs, and then determining how to measure each one, become the key steps in understanding and measuring system level complexity in this view.
The following sections describe five such continuums; more may be possible.
Control plane state is the aggregate amount of information carried by the control plane through the network in order to produce the forwarding table at each device. Each additional piece of information added to the control plane --such as more specific reachability information, policy information, additional control planes for virtualization and tunneling, or more precise topology information-- adds to the complexity of the control plane. This added complexity, in turn, adds to the burden of monitoring, understanding, troubleshooting, and managing the network.
Removing control plane state, however, is not always a net positive gain for the network as a system; removing control plane state almost always results in decreased optimality in the forwarding and handing of packets travelling through the network. This decreased optimality can be termed stretch, which is defined as the difference between the absolute shortest (or best) path traffic could take through the network and the path the traffic actually takes. Stretch is expressed as the difference between the optimal and actual path. The figure below provides and example of this tradeoff.
+---R1---+
| |
(aggregate: 192.0.2/24) R2 R3 (aggregate: 192.0.2/24)
| |
R4-------R5
|
(announce: 192.0.2.1/32) R6
Assume each link is of equal cost in this figure, and R6 is advertising 192.0.2.1/32.
For R1, the shortest path to 192.0.2.1/32, advertised by R6, is along the path [R1,R2,R4,R6].
Assume, however, the network administrator decides to aggregate reachability information at R2 and R3, advertising 192.0.2.0/24 towards R1 from both of these points. This reduces the overall complexity of the control plane by reducing the amount of information carried past these two routers (at R1 only in this case).
Aggregating reachability information at R2 and R3, however, may have the impact of making both routes towards 192.0.2.1/32 appear as equal cost paths to R1; there is no particular reason R1 should choose the shortest path through R2 over the longer path through R3. This, in effect, increases the stretch of the network. The shortest path from R1 to R6 is 3 hops, a path that will always be chosen before aggregation is configured. Assuming half of the traffic will be forwarded along the path through R2 (3 hops), and half through R3 (4 hops), the network is stretched by ((3+4)/2) - 3), or .5, a "half a hop."
Traffic engineering through various tunneling mechanisms is, at a broad level, adding control plane state to provide more optimal forwarding (or network utlization). Optimizing network utilization may require detuning stretch (intentionally increasing stretch) to increase overall network utilization and efficiency; this is simply an alternate instance of control plane state (and hence complexity) weighed against optimal forwarding through the network.
A failure domain, within the context of a network control plane, can be defined as the set of devices impacted by a change in the network topology or configuration. A network with larger failure domains is more prone to cascading failures, so smaller failure domains are normally preferred over larger ones.
The primary means used to limit the size of a failure domain within a network's control plane is information hiding; the two primary types of information hidden in a network control plane are reachability information and topology information. An example of aggregating reachability information is summarizing the routes 192.0.2.1/32, 192.0.2.2/32, and 192.0.2.3/32 into the single route 192.0.2.0/24, along with the aggregation of the metric information associated with each of the component routes. Note that aggregation is a "natural" part of IP networks, starting with the aggregation of individual hosts into a subnet at the network edge. An example of topology aggregation is the summarization of routes at a link state flooding domain boundary, or the lack of topology information in a distance-vector protocol.
While limiting the size of failure domains appears to be an absolute good in terms of network complexity, there is a definite tradeoff in configuration complexity. The more failure domain edges created in a network, the more complex configuration will become. This is particularly true if redistribution of routing information between multiple control plane processes is used to create failure domain boundaries; moving between different types of control planes causes a loss of the consistent metrics most control planes rely on to build loop free paths. Redistribution, in particular, opens the door to very destructive positive feedback loops within the control plane. Examples of control plane complexity caused by the creation of failure domain boundaries include route filters, routing aggregation configuration, and metric modifications to engineer traffic across failure domain boundaries.
Returning to the network described in the previous section, aggregating routing information at R2 and R3 will divide the network into two failure domains: (R1,R2,R3), and (R2,R3,R4,R5). A failure at R5 should have no impact on the forwarding information at R1.
A false failure domain separation occurs, however, when the metric of the aggregate route advertised by R2 and R3 is dependent on one of the routes within the aggregate. For instance, if the metric of the 192.0.2.0/24 aggregate is derived from the metric of the component 192.0.2.1/32, then a failure of this one component will cause changes in the forwarding table at R1 --in this case, the control plane has not truly been separated into two distinct failure domains. The added complexity in the illustration network would be the management of the configuration required to aggregate the contorl plane information, and the management of the metrics to ensure the control plane is truly separated into two distinct failure domains.
Replacing aggregation with redistribution adds the complexity of managing the feedback of routing information redistributed between the failure domains. For instance, if R1, R2, and R3 were configured to run one routing protocol, while R2, R3, R4, R5, and R6 were configured to run another protocol, R2 and R3 could be configured to redistribute reachability information between these two control planes. This can split the control plane into multiple failure domains (depending on how, specifically, redistribution is configured), but at the cost of creating and managing the redistribution configuration. Futher, R3 must be configured to block routing information redistributed at R2 towards R1 from being redistributined (again) towards R4 and R5.
Another broad area where control plane complexity interacts with optimal network utilization is Quality of Service (QoS). Two specific actions are required to optimize the flow of traffic through a network: marking and Per Hop Behaviors (PHBs). Rather than examining each packet at each forwarding device in a network, packets are often marked, or classified, in some way (typically through Type of Service bits) so they can be handled consistently at all forwarding devices.
Packet marking policies must be configured on specific forwarding devices throughout the network. Distributing marking closer to the edge of the network necessarily means configuring and managing more devices, but produces optimal forwarding at a larger number of network devices. Moving marking towards the network core means packets are marked for proper handling across a smaller number of devices. In the same way, each device through which a packet passes with the correct PHBs configured represents an increase in the consistency in packet handling through the network as well as an increase in the number of devices which must be configured and managed for the correct PHBs. The network below is used for an illustration of this concept.
+----R1----+ | | +--R2--+ +--R3--+ | | | | R4 R5 R6 R7
In this network, marking and PHB configuration may be configured on any device, R1 through R7.
Assume marking is configured at the network edge; in this case, four devices, (R4,R5,R6,R7), must be configured, including ongoing configuration management, to mark packets. Moving packet marking to R2 and R3 will halve the number of devices on which packet marking configuration must be managed, but at the cost of inconsistent packet handling at the inbound interfaces of R2 and R3 themselves.
Thus reducing the number of devices which must have managed configurations for packet marking will reduce optimal packet flow through the network. Assuming packet marking is actually configured along the edge of this network, configuring PHBs on different devices has this same tradeoff of managed configuration versus optimal traffic flow. If the correct PHBs are configured on R1, R2, and R3, then packets passing through the network will be handled correctly at each hop. The cost involved will be the management of PHB configuration on three devices. Configuring a single device for the correct PHBs (R1, for instance), will decrease the amount of configuration management required, at the cost of less than optimal packet handling along the entire path.
The number of PHBs configured along a forwarding path exhibits the same complexity versus optimality tradeoff described in the section above. The more classes (or queues) traffic is divided into, the more fine-grained traffic will be managed as it passes through the network. At the same time, each class of service must be managed, both in terms of configuration and in its interaction with other classes of service configured in the network.
The speed at which the network's control plane can react to a change in configuration or topology is an area of widespread study. Control plane convergence can be broken down into four essential parts:
Each of these areas can be addressed in an effort to improve network convergence speeds; some of these improvements come at the cost of increased complexity.
Changes in network topology can be detected much more quickly through faster echo (or hello) mechanisms, lower layer physical detection, and other methods. Each of these mechanisms, however, can only be used at the cost of evaluating and managing false positives and high rates of topology change.
If the state of a link change can be detected in 10ms, for instance, the link could theoretically change state 50 times in a second --it would be impossible to tune a network control plane to react to topology changes at this rate. Injecting topology change information into the control plane at this rate can destabalize the control plane, and hence the network itself. To counter this, most fast down detection techniques include some form of dampening mechanism; configuring and managing these dampening mechanisms increases complexity that must be configured and managed.
Changes in network topology must also be propagated throughout the network, so each device along the path can compute new forwarding tables. In high speed network environments, propagation of routing information changes can take place in tens of milliseconds, opening the possibility of multiple changes being propagated per second. Injecting information at this rate into the contral plane creates the risk of overloading the processes and devices participating in the control plane, as well as creating destructive positive feedback loops in the network. To avoid these consequences, most control plane protocols regulate the speed at which information about network changes can be transmitted by any individual device. A recent innovation in this area is using exponential backoff techniques to manage the rate at which information is advertised into the control plane; the first change is transmitted quickly, while subsequent changes are transmitted more slowly. These techniques all control the destabalilzing effects of rapid information flows through the control plane through the added complexity of configuring and managing the rate at which the control plane can propagate information about network changes.
All control planes require some form of algorithmic calculation to find the best path through the network to any given destination. These algorithms are often lightweight, but they still require some amount of memory and computational power to execute. Rapid changes in the network can overwhelm the devices on which these algorithms run, particularly if changes are presented more quickly than the algorithm can run. Once the devices running these algorithms become processor or memory bound, it could experience a computational failure altogether, causing a more general network outage. To prevent computational overloading, control plane protocols are designed with timers limiting how often they can compute the best path through a network; often these timers are exponential in nature, allowing the first computation to run quickly, while delaying subsequent computations. Configuring and managing these timers is another source of complexity within the network.
Another option to improve the speed at which the control plane reacts to changes in the network is to precompute alternate paths at each device, and possibly preinstall forwarding information into local forwarding tables. Additional state is often needed to precompute alternate paths, and additional algorithms and techniques are often configured and deployed. This additional state, and these additional algorithms, add some amount of complexity to the configuration and management of the network.
In some situations (for some topologies), a tunnel is required to pass traffic around a network failure or topology change. These tunnels, while not manually configured, represent additional complexity at the forwarding and control planes.
In Section 3 we describe a set of trade-offs in network design to illustrate the practical choices network operators have to make. The amount of parameters to consider in such tradeoff scenarios is very large, thus that a complete listing may not be possible. Also the dependencies between the various metrics itself is very complex and requires further study. This document attempts to define a methodology and an overall high level structure.
To analyse tradeoffs it is necessary to formalise them. The list of parameters for such tradeoffs is long, and the parameters can be complex in themselves. For example, "cost" can be a simple unidimensional metric, but "extensibility" or "optimal forwarding state" are harder to define in detail.
A list of parameters to trade off contains metrics such as:
Complexity can be found in various elements in a networked system. For example, the configuration of a network element reflects some of the complexity contained in this system. Or an algorithm used by a protocol may be more or less complex. When classifying complexity the first question to ask is "WHAT is complex?". This section offers a method to answer this question.
The set of network devices and wiring contains a certain complexity. For example, adding a redundant link between two locations increases the complexity of the network, but provides more redundancy. Also network devices can be more or less modular, which has impact on complexity trading off against ease of maintenance, availability and upgradability.
The behavior of the physical network is not only defined by the hardware, but also by algorithms that run on network elements and in central locations. Every algorithm has a certain intrinsic complexity, which is the subject of research on software complexity.
The way a network element treats traffic is defined largely by the state in the network, in form of configuration, routing state, security measures, etc. Section 3.1 shows an example where more control plane state allows a more precise forwarding.
The rate of change itself is a parameter in complexity, which needs to be weighed against other parameters. Section 3.5 explains a trade-off between the speed of communicating changes through the network and the stability of the network.
Certain complexity parameters have a strong link to the human aspect of networking. For example, the more option and parameters a network protocol has, the harder it is to configure and trouble-shoot. Therefore, there is a trade-off between the knowledge to be maintained by operational staff and desired functionality. The required knowledge of network operators is therefore an important part in complexity considerations.
The previous section discussed in which form complexity may be perceived. This section focuses on where this complexity is located in a network. For example, an algorithm can run centrally, distributed, or even in the head of a network administrator. In classifying the complexity of a network, the location of a component may have an impact on overall complexity. This section offers a methodology to the question "WHERE is the complex component?"
An algorithm can run distributed, for example a routing protocol like OSPF runs on all routers in a network. But it can also be in a central location such as the Network Operations Center (NOC). The physical location has impact on several other parameters, such as availability (local changes might be faster than going through a remote NOC) and ease of operation, because it might be easier to understand and troubleshoot one central entity rather than many remote ones.
The example in Section 3.3 shows how the location of state (in this case configuration) impacts the precision of the policy enforcement and the corresponding state required. Enforcement closer to the edge requires more network wide state, but is more precise.
Independent of its physical location, the logical location also may make a difference to complexity. A controller function for example can reside in a NOC, but also on a network element. Generally, organising a network in separate logical entities is considered positive, because it eases the understanding of the network, thereby making trouble-shooting and configuration easier. For example a BGP route reflector is a separate logical entity from a BGP speaker, but it may reside on the same physical node.
Also the layer of the TCP/IP stack in which a function is implemented can have an impact on the complexity of the overall network. Some functions are implemented in several layers in slightly different ways, which may lead to unexpected results.
As an example, a link failure is detected on various layers: L1, L2, the IGP, BGP, and potentially more. Since those have dependencies on each other, different link failure detection times can cause undesired effects. Dependencies are discussed in more detail in the next section.
Dependencies are generally regarded as related to overall complexity. A system with less dependencies is generally considered less complex. This section proposes a way to analyse dependencies in a network.
For example, [Chun] states: "We conjecture that the complexity particular to networked systems arises from the need to ensure state is kept in sync with its distributed dependencies."
In this document we distinguish three types of dependencies: Local dependencies, network wide dependencies, and network external dependencies.
Local dependencies are relative to a single node in the network. For example, an interface on a node may have an IP address; this address may be used in other parts of the configuration. If the interface address changes, the dependent configuration parts have to change as well.
Similar dependencies exist for QoS policies, access-control-lists, names and numbers of configuration parts, etc.
Routing protocols, failover protocols, and many other have dependencies across the network. If one node is affected by a problem, this may have a ripple effect through the network. These protocols are typically designed to deal with unexpected consequences, thus unlikely to cause an issue on their own. But occasionally a number of complexity issues come together, for example, different timers on different layers, then unexpected behaviour can occur.
Some dependencies are on elements outside the actual network, for example on an external NTP clock source, or a AAA server. Again, a tradeoff is made: In the example of AAA used for login authentication, we reduce the configuration (state) on each node, specifically user specific configuration. But we add an external dependency on a AAA server. In networks with many administrators, a AAA server is clearly the only manageable way to track all administrators. But it comes at the cost of this external dependency, with the consequence that admin access may be lost for all devices at the same time, when the AAA server is unavailable.
Even with the external dependency on a AAA server, the advantage of centralizing the user information (and logging) still has significant value over distributing user information across all devices. To solve the problem of the central dependency not being available, other solutions have been developed, for example a secondary authentication mode with a single root level password in case the AAA server is not available.
A static network generally is relatively stable; conversely, changes introduce a degree of uncertainty and therefore need to be examined in detail. Also, the trouble shooting of a network exposes intuitively the complexity of the network. This section proposes a methodology to classify management interactions with regard to their relationship to network complexity.
Configuration can be seen as distributed state across network devices, where the administrator has direct influence on the operation of the network. Modifying the configuration can improve the network behaviour over all, or negatively affect it. In the worst case, a single misconfiguration could potentially bring down the entire network. Therefore it is important that a human administrator can manage the complexity of the configuration well.
The configuration reflects most of the local and global dependencies in the network, as explained in Section 7. Tracking those dependencies in the configuration helps in understanding the overall network complexity.
Unexpected behaviour can have a number of sources: The configuration may contain errors, the operating system (algorithms) may have bugs, and the hardware may be faulty, which includes anything from broken fibres to faulty line cards. In serious problems, a combination of causes could result in a single visible condition. Tracking the root causes of a error condition may be extremely difficult, pointing to the complex nature of a network.
Being able to find the source of a problem requires therefore a solid understanding of the complexity of a network. The configuration complexity discussed in the previous section represents only a part of the overall problem space.
Even in the absence of error conditions, the state of the network should be monitored to detect error conditions ideally before network services are affected. For example, a single "link-down" event may not cause a service disruption in a well designed network, but the problem needs to be resolved quickly to restore redundancy.
Monitoring a network has itself a certain complexity. Issues are in scale, variations of devices to be monitored, variations of methods used to collect information, the inevitable loss of information as reporting is aggregated centrally, and the knowledge required to understand the network, the dependencies and interactions with users and other external inputs.
A network doesn't just consist of network devices, but includes a vast array of backend and support systems. It also interfaces a large variety of user devices, and a number of human interfaces, both to the user / customer, as well as to administrators of the network. To make sure the overall network provides the overall service expected requires a system integration job.
All those interactions and systems have to be modelled to understand the inter-dependencies and complexities in the network. This is a large area of future research.
A network is not a self-contained entity, but exists to provide connectivity and services to users and other networks, both of which are outside the direct control of a network administrator. The user experience of a network also illustrates a form of interaction with its own complexity.
External interactions fall into the following categories:
For a fully operational network providing services to users, also the external interactions and dependencies form an integral part of the overall complexity of the network service. A specific example are the root DNS servers, which are critical to the function of the Internet. Practically all Internet users have an implicit dependency on the root DNS servers, which explains why those are frequent targets for attacks. Understanding the overall complexity of a network includes understanding all those external dependencies. Of course, in the case of the root DNS servers, there is little a network operator can influence.
In the foreseeable future it is unlikely to define a single, objective metric that includes all the relevant aspects of complexity. In the absence of such a global metric, a comparative approach could be easier.
For example, it is possible to compare the complexity of a centralised systems where algorithms run centrally, and the results are distributed to the network nodes with a distributed algorithm. The type of algorithm may be similar, but the location is different, and a different dependency graph would result. The supporting hardware may be the same, thus could be ignored for this exercise. Also layering is likely to be the same. The management interactions though would significantly differ in both cases.
The classification in this document also makes it easier to survey existing research with regards to which area of complexity is covered. This could help in identifying open areas for research.
This document does not discuss any specific security considerations.
The motivations and framework of this overview of studies into network complexity is the result of many meetings and discussions, with too many people to provide a full list here. However, key contributions have been made by: John Doyle, Dave Meyer, Jon Crowcroft, Mark Handley, Fred Baker, Paul Vixie, Lars Eggert, Bob Briscoe, Keith Jones, Bruno Klauser, Steve Youell, Joel Obstfeld, Philip Eardley.
The authors would like to acknowledge the contributions of Rana Sircar, Ken Carlberg and Luca Caviglione in the preparation of this document.
| [Behringer] | Behringer, M., "Classifying Network Complexity", Proceedings of the ACM Re-Arch'09, December 2009. |
| [Chun] | Chun, B-G., Ratnasamy, S. and E. Eddie, "NetComplex: A Complexity Metric for Networked System Design", 5th Usenix Symposium on Networked Systems Design and Implementation NSDI 2008, April 2008. |
| [Doyle] | Doyle, J., "The 'robust yet fragile' nature of the Internet", PNAS vol. 102 no. 41 14497-14502, October 2005. |
| [ncrg] | Network Complexity Research Group" | , "
| [RFC1925] | Callon, R., The Twelve Networking Truths", RFC 1925, DOI 10.17487/RFC1925, April 1996. |
| [RFC3439] | Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, DOI 10.17487/RFC3439, December 2002. |
| [wiki] | Network Complexity Wiki" | , "