IRTF Network Complexity Research Group Wednesday, March 13, 2013, 13.00-15.00 Chair: Michael Behringer Scribe: Benno Overeinder * Opening and agenda bashing * David Meyer, Seeing The Past, Present and Future http://www.ietf.org/proceedings/86/slides/slides-86-ncrg-0.pdf Kevin Fall: The popularity of SDN brings deep question on software development. Software is cement of this community to build inovation. But software is inherently nonlinear, what do you mean by that? Dave: Software is fragile, by the way it is build. And fragile in the way it operates. Consider agile software development or XP, they take advantage of the variability that is causing the fragility. Kevin: Agile and XP are an reaction on waterfall methods, which builds software in rigid but predictable in concert with requirements. It is an open and interesting question how the pressures are between architectural design and an agile process to get this supported, I don't know it is inherently nonlinear. There are large systems designed by people who won't agree that it is nonlinear. SDN could benefit from software development methodology and formal methods, and SDN is highlighting the fact we could do that: it underscores the importance of software. Dave: Work of Doyle on complexity is connecting these three things. The ideas of fragility, the nonlinearity that is associated with fragility, and the fact that this goes all into software. And all of these principals also apply there and our understanding is less, is (what I am claiming) is the real effect of SDN. Scott Whyte: Are you confining SDN and OpenFlow (are not the same)? Dave: Yes, the are not the same thing. Scott: Emergent property is a new thin waist. The network stack is below, and all the new software is above. Dave: Yes, it is heavily layered. The can be a waist inside the layer, or between the layers. Dave Israel: Most standard bodies and vendors will do a 80/20 rule. SDN gives the 20 percent the chance to build something at network speed without the vendors or standards organisation are willing to give them. If I build my own appliance, e.g., home router with Raspberry Pi, I take the risk to build something (complexity) hardware vendors do not sell. Shen Shuo (?): SDN delay between switch and controller, and single point of failure. For robustness multiple controllers, but then synchronization problem. Current networks run on configurations, SDN runs on software, and arguably, software is more complex than configurations. Do you thing SDN networks are less complex or more complex? Dave: Complex or not complex, it is really about structure that is in place that provides robustness. In case of SDN, component wise it is more complex, but there is more volatility---randomness you can not predict. Shen: This unpredictability comes from software? Dave: More randomness, open loops, robust control, and hidden second order effects. I think it is more complex, not less. But if you want to scale, you need programmatic automation and configuration management, ... and that all needs to be programmatic. Olaf Kolkman: Is there a recommendation/future you pulling away from it. What is your personal conclusion and vision forward? Dave: What does the SDN stuff mean, complexity and some kind of notion of fragility. What are the properties. Many systems are exposed to a great deal of volatility, and have evolved algorithmes that goes with that. In engineering we took away of all volatility. This would be wrong if the Internet is like one of these systems. The question is how do we build this kind of systems? This anti-fragility stuff is about this. In the future automated learning (or anti-fragile), systems become better by virtue of this volatility. Removing volatility can make the system fragile (analogy with Yellow Stone forest fires). Dough Montgomery: What is the role of standardization here? Do you envision standardized SDN implementations or routing designs? Dave: Routing and IP layers is in the waist (stable part). SDN is above that, it has unbounded volatility availability to it. Doug: SDN being standardized above the mechanistic level that exists now? Dave: I don't think so. Doug: ... there are indefinite number of bad ideas on routing ... Dave: ... it is an open loop ... Bill Manning: Differences in behaviour at different levels (molecular/cell/...) stable in a level, might not be stable on higher level. There seems an assumption of linearity between what we do now and future systems we build. There is probably a boundary condition that rules that apply here, won't apply somewhere below. Dave: Emergent behavior? Weak emergence you can decompile. Strong emergence where the properties are irreducible. And irreducibility doesn't fit us well. Dimitri Papadimitriou: Make a difference between architectural complexity and algorithmic complexity? You are speaking about architectural complexity and algorithmic complexity (of size N)? Complexity of programs in Kolgomorov complexity view. Dave: Algorithmic complexity in OpenFlow context, the number of table entries. Ted Hardy: The difference between hardware and software complexity is the rate of change is different. It is about adaptive radiation. With software it has ability to radiate quickly. You can explore paths through your network. But you want to stay with the current internet, so the ways to radiate from the current state is limited: different optimality. Is there a way to overcome the sub-optimality. Dave: Scalable systems that are adoptable and evolvable. If we have the hour glass model, are we violating this? And what are we doing with SDN/OpenFlow. Dimitri: The cost of evolution in software vs. hardware. Reprogramming hardware vs. software have different costs to the evolution step. Dave: This exactly the point of Ted: the ability to radiate quickly. * Sheng Jiang, Diverting the Network Complexity http://www.ietf.org/proceedings/86/slides/slides-86-ncrg-1.pdfslidee Olivier Festor: What is missing for automated network management (we have policy management)? Fault processing, how make sure users do not divert the system? So what is missing? Sheng: First part, we are not fully understanding the requirements from the providers. Every ISP has different requirements, which are not well-defined. We need to translate the specific ISP requirements to generic requirements. Michael Behringer: Interesting generic question for later discussion. Olivier: More specific question. What did you make think adding some bits to the prefix makes your problem solve? Sheng: It is about what kind of semantic you put in there. How to get meaning out of the packets. There are many forwarding policies how to distinguish between packets, and this can help you. Michael: For next time, not only present what the semantic prefix is, but what its complexity and how it relates to this research group. * Michael Behringer, Framework draft http://tools.ietf.org/html/draft-irtf-ncrg-complexity-framework-00 Document is now a research group document. Overview of document history. Overall scope of document has not changed. We have to define complexity more precisely. Furthermore we need measurements, numbers. Currently we have none, any number is better than nothing. There many design considerations that have some complexity number associated with. Dimitri: Where is the complexity? The placement aspects plays a role in the network complexity questions. Framework draft: - a framework for defining network complexity - current understanding - toward defining network complexity - possible directions - sub-group to continue works on this document With SDN, what are the implications on network complexity? For progress, need involvement and contributions from individuals. E.g., these are the numbers of increased complexity of SDN, throw it in. Or a comparison, or a use-case ... Some thoughts how we could improve on it. So anything that gives statements to frame the problem right now, who get us further. If you want to contribute to the framework draft, please let chairs know. Comments? Dave Meyer: Introduce control systems knowledge into this community. Try to write the document to get this controls system knowledge into this group. Michael: Indeed, but problem with these generic models, ok, but can we quantify this. E.g., complexity is in these components, this is how it accounts. And if you don't have it, this is what you save, but you lose in this side. Need to become more descriptive. Allison Mankin: Collocating with academic complexity group. Does that have come up at all? Michael: Please send suggestions. Dave: Great suggestion. It's bottom up, we feed the complexity guys. Kevin: There is a 2006 HotNets paper "Capturing Complexity in Networked Systems Design: The Case for Improved Metrics", for those who are interested. Michael: Thanks, we have invited Sylvia but couldn't make it. See also NetworkComplexity.org wiki. Michael: Any fundamental questions, or doubts? Dave: Two things: what is underneath this stuff? And what are the salient architecture features that lead to complexity (basically structure in these systems). And how can we create engineering metrics to do comparisons. * Closed.