Complex Systems & Autonomic Networks, Part 5: Emergence in Networks

Emergence in Networks

“…, networks evolve over time through the actions of network users, changes in types of access to the networks, and interconnections between networks. … changes to one part of the network can affect the performance and evolution of the network in ways that can be dramatic and unpredictable.”
- Daniel F. Spulber & Christopher S. Yoo

---

Instability: It is actually difficult to understand, to realize, when a network goes unstable. In the beginning a larger than normal series of problems will occur. These problems are treated in isolation and standard fixes are applied. These fixes either do not take, or the problem just shifts to somewhere else, often an adjacent area. The number of problems rapidly increases, showing similar symptoms, but no rational cause for why this is occurring.

A NOC just following procedure scripts will only see the individual problems. Centralized systems must add up the total number of problems per unit of time, class them as similar, and then trend them to give early prediction of the onset of an unstable network occurrence. Regardless, eventually this becomes obvious, when the point is reached where the network cannot do its job or even shuts down. How can we best see these problems as they occur and better yet, build systems which accommodate and correct for these problems?

“Emergence is the process of complex pattern formation from simpler rules… An emergent behaviour or emergent property can appear when a number of simple entities (agents) operate in an environment, forming more complex behaviours as a collective…. Thus it is not just the sheer number of connections between components which encourages emergence; it is also how these connections are organised. A hierarchical organisation is one example that can generate emergent behaviour (a bureaucracy may behave in a way quite different to that of the individual humans in that bureaucracy); but perhaps more interestingly, emergent behaviour can also arise from more decentralized organisational structures, such as a marketplace.”
- http://en.wikipedia.org/wiki/Emergence

Studying complex systems and emergent behavior will give two specific powers: (1) a better ability to visualize what is going on in the network as a whole and within any network subpart; and (2) an ability to design stable complex systems. In the following, we look at the structure of emergent systems, designing for stability, and introduce agents as design patterns for network OSS.

“Emergence is what happens when the whole is smarter than the sum of its parts. It’s what happens when you have a system of relatively simple-minded component parts — often there are thousands or millions of them — and they interact in relatively simple ways. And yet somehow out of all this interaction some higher level structure or intelligence appears, usually without any master planner calling the shots. These kinds of systems tend to evolve from the ground up.”
- O’Reilly Network Interview with Steven Johnson

Visualization: Most of the time, emergence and complex systems are approached as mechanisms for supporting very large systems. Complex systems are designed to accommodate very large structures.

“Emergent systems… would not be overwhelmed by this volume and are, in fact, a natural solution to such hugely complex problems. The question then becomes, do our current systems, business plans, and curricula reflect our understanding that hierarchical systems are only a temporary solution, and are we ready to implement the systems, business plans, and curricula that will be a part of the emergent technologies that will be useful and necessary in the near future?”
- from a review of Johnson’s Emergence by Chris Leslie

Yet there is not just a scaling problem for OSS products and systems - there is a visualization problem.

Much of the problem with understanding and fixing networks is the sheer size of modern networks. Much effort is spent just documenting additions and deletions and drawing network maps. Sometimes as we have shown, the maps themselves distort perception of the network, but even with perfect maps, there is just too much there for people to comprehend. Sometimes the best experts are said to “have a feel” for the network. Generally these operators, without being able to explain how they know what to do, can put their finger on a problem and suggest a approach to fixing it. I maintain that these operators have subconsciously grasped the complex system dynamics and are responding to that, rather than to details. This is why it is so difficult for knowledge experts to generalize top-down rules from speaking with these rare operational experts.

Stability: The most interesting aspect of Emergence (to OSS & network builders) is that emergence often leads to stability in complex systems. The most interesting property is goal directed behavior can lead to emergent stability. Emergent systems design builds actor agents which push back against instabilities - so that any displacement from equilibrium or noise introduced into a system destabilizes the system only for a short time, before stability is again achieved - without external action.

“A hierarchical, top-down system attempts to use a centralized decision-making process based on abstract rules to guide behavior. The emergent position looks at complex systems differently: a small number of rules that are processed by individual units are the best method of explaining the aggregate behavior. While a statistical analysis of an emergent system will lead to abstract mathematical laws, these laws do not explain why individual units behave the way they do.”
- from a review of Johnson’s Emergence by Chris Leslie

Establishing system boundaries: When designing for autonomic networks, agents introduced into the system would act to restore the system dynamics. Some think that in a fully automated network it would not be necessary to call upon operators in a NOC to take action to restore the system. The actions of the software agents would automatically bring back stability. But getting the complete set of rules for these agents is extremely hard and the network and product mix is changing all the time.

Alternatively, one can consider the operators in the NOC to be part of the autonomic network system. In this view, operators are ‘living agents’. As such, ideally, their actions should be able to be encoded as rules; but we know this is extraordinarily difficult. This is partly why rule based systems when applied to network alarm identification and response; do not give the good results that were expected.

Instead, following our understanding of complex systems, we could use a number of different disciplines to model the actions of the NOC operator - depending on if we wanted to be proscriptive (please behave this way) or prescriptive (tell me how you would behave in this situation to get this result). Basically, in classical OSS, designers build a script for operators to follow for customer relations or a process to follow for network restoration. But in reality the operator will not always follow these rules and process, often diverting because new situations arise, or even because they are bored and begin to experiment (a normal human behavior). In this case fuzzy logic is needed to model the operators.

Fuzzy logic: Basically fuzzy logic lets things fall into multiple sets or partially reside in a specific set. Programmatically, it involves using rules of “If Then” form and not rules of “If Then Else” form; and many rules can be true at once. In building an OSS agent, we can attempt to model and program all the behaviors a NOC operator might take or has taken in the past. But how would a specific action be selected from the many possible actions during run time? For this we might apply Bayesian utility theory and assign weights to the actions. These weights help conscribe the action of the model operator agent via internal agent control rules: such as by weighting the probability function when random selection is used to chose which of the many true rules to implement this time. Such designs allow evolving systems to occur.

Iterative design: In evolving systems, the weights for these rules will change over time based on the perceived, in aggregate, degree of successful actions that the rule participated in. Of course, the trick is recognizing success and then programming this feedback of changed weights. Recognizing “what is success” is itself a fuzzy construct with many values to the set. In this design model, by small iterative improvements, over time the network system will become stable; the rule weights reasonably mature and changing only in small amounts. With small changes to agents whose action is localized to a specific subpart, interactive changes cascade through the system. If the criteria for weighting the rules were empirically measured and success- based, emergent stability is achieved. But predicting outcomes of rule changes, prior to implementation, is difficult.

Alternately, we can cluster associated rules into generalized behaviors. We then put each separate rule cluster (a subset of all rules describing possible behaviors) into a separate agent. By describing some form of inter-agent, top-down control (such as one of several types of transactions, or sequence calls, etc.), we attempt to gain a systems dynamic in which emergent system behavior arises.

“There is nothing that commands the system to form a pattern, but instead the interactions of each part to its immediate surroundings causes a complex process which leads to order.”
- [ http://en.wikipedia.org/wiki/Emergence]

Self organizing & self provisioning: The best agent managed system will be self organizing. If the agents can themselves determine what other agents to interact with in every instance, the overall network system is beginning to become truly autonomic. There is reason to believe this would deliver an extremely stable, inexpensive to operate network.

“In some cases, the system has to reach a combined threshold of diversity, organisation, and connectivity before emergent behaviour appears.”
- [ http://en.wikipedia.org/wiki/Emergence]

Having only a few agents will not result in emergent stable networks. Classical OSS, combined with Enterprise Resource Planning (ERP), and the postulates of the “lean operator” have resulted in reducing the number of management systems and NOCs in most providers. It is paradoxical, but while this will reduce immediate operational expense, ultimately, consolidation of NOCs and management systems will increase costs. Over the long run, NOC and ERP- based application aggregation lead to a greater composite sum of costs than having a large number of simpler, specializing NOCs. This is counterintuitive; but consider the simple case of the rare, extreme disaster such as a routing instability or security breech. The costs of recovery can run large enough to add significantly to the life-time sum of costs of the network. The probability of a destabilizing decision is greater when one entity makes the call, rather than a number of entities debating the call. Remember the old adage: “There are only networks which have catastrophically failed, and networks which have yet to catastrophically fail.”

But many NOCs, many applications, many agents, many alternative actions an agent can take - this is complexity. If you attempted to manage this with traditional methods, the sheer complexity would overwhelm you. There must be a class of autonomic management agents that oversee the provisioning and health of these agents. This then leads to survivable systems design. One ends up with a “Mirror World” composed of a complex system of agents that models a complex network.

This was a fast overview of emergence and agents as actors in emergence-aware design. In the next two parts I will outline (Part 6) a revisualization of the network so that emergent behavior can be identified, while showing the fallacy of the point fix; and (Part 7) how to build autonomous agent systems, as described above, that could enforce stabilizing behavior in networks.

Wedge Greene is a consultant for LTC International.