scispace - formally typeset
Search or ask a question
Author

Eugene Huang

Bio: Eugene Huang is an academic researcher from University of California, Berkeley. The author has contributed to research in topics: Software bug & Troubleshooting. The author has an hindex of 2, co-authored 2 publications receiving 106 citations.

Papers
More filters
Proceedings ArticleDOI
17 Aug 2014
TL;DR: This paper presents a technique for automatically identifying a minimal sequence of inputs responsible for triggering a given bug, without making assumptions about the language or instrumentation of the software under test.
Abstract: Software bugs are inevitable in software-defined networking control software, and troubleshooting is a tedious, time-consuming task. In this paper we discuss how to improve control software troubleshooting by presenting a technique for automatically identifying a minimal sequence of inputs responsible for triggering a given bug, without making assumptions about the language or instrumentation of the software under test. We apply our technique to five open source SDN control platforms---Floodlight, NOX, POX, Pyretic, ONOS---and illustrate how the minimal causal sequences our system found aided the troubleshooting process.

90 citations

01 Jan 2013
TL;DR: This paper applies retrospective causal inference to three open source SDN control platforms—Floodlight, POX, and NOX—and illustrates how the technique found minimal causal sequences for the bugs the authors encountered.
Abstract: Software bugs are inevitable in software-defined networking (SDN) control planes, and troubleshooting is a tedious, time-consuming task. In this paper we discuss how one might improve SDN network troubleshooting by presenting a technique, retrospective causal inference, for automatically identifying a minimal sequence of inputs responsible for triggering a given bug in the control software. Retrospective causal inference works by iteratively pruning inputs from the history of the execution, and coping with divergent histories by reasoning about the functional equivalence of events. We apply retrospective causal inference to three open source SDN control platforms—Floodlight, POX, and NOX—and illustrate how our technique found minimal causal sequences for the bugs we encountered.

18 citations


Cited by
More filters
Proceedings ArticleDOI
22 Jun 2015
TL;DR: This paper addresses one serious SDN-specific attack, i.e., data-to-control plane saturation attack, which overloads the infrastructure of SDN networks and introduces an efficient, lightweight and protocol-independent defense framework forSDN networks.
Abstract: This paper addresses one serious SDN-specific attack, i.e., data-to-control plane saturation attack, which overloads the infrastructure of SDN networks. In this attack, an attacker can produce a large amount of table-miss packet_in messages to consume resources in both control plane and data plane. To mitigate this security threat, we introduce an efficient, lightweight and protocol-independent defense framework for SDN networks. Our solution, called FloodGuard, contains two new techniques/modules: proactive flow rule analyzer and packet migration. To preserve network policy enforcement, proactive flow rule analyzer dynamically derives proactive flow rules by reasoning the runtime logic of the SDN/OpenFlow controller and its applications. To protect the controller from being overloaded, packet migration temporarily caches the flooding packets and submits them to the OpenFlow controller using rate limit and round-robin scheduling. We evaluate FloodGuard through a prototype implementation tested in both software and hardware environments. The results show that FloodGuard is effective with adding only minor overhead into the entire SDN/OpenFlow infrastructure.

306 citations

Proceedings ArticleDOI
03 Nov 2014
TL;DR: ROSEMARY is presented, which implements a network application containment and resilience strategy based around the notion of spawning applications independently within a micro-NOS, and it is found that with the integration of two optimization features, ROSEMARY offers a competitive performance advantage over the majority of other controllers.
Abstract: Within the hierarchy of the Software Defined Network (SDN) network stack, the control layer operates as the critical middleware facilitator of interactions between the data plane and the network applications, which govern flow routing decisions. In the OpenFlow implementation of the SDN model, the control layer, commonly referred to as a network operating system (NOS), has been realized by a range of competing implementations that offer various performance and functionality advantages: Floodlight, POX, NOX, and ONIX. In this paper we focus on the question of control layer resilience, when rapidly developed prototype network applications go awry, or third-party network applications incorporate unexpected vulnerabilities, fatal instabilities, or even malicious logic. We demonstrate how simple and common failures in a network application may lead to loss of the control layer, and in effect, loss of network control. To address these concerns we present the ROSEMARY controller, which implements a network application containment and resilience strategy based around the notion of spawning applications independently within a micro-NOS. ROSEMARY distinguishes itself by its blend of process containment, resource utilization monitoring, and an application permission structure, all designed to prevent common failures of network applications from halting operation of the SDN Stack. We present our design and implementation of ROSEMARY, along with an extensive evaluation of its performance relative to several of the mostly well-known and widely used controllers. Rather than imposing significant performance costs, we find that with the integration of two optimization features, ROSEMARY offers a competitive performance advantage over the majority of other controllers.

225 citations

Journal ArticleDOI
TL;DR: This paper seeks to identify some of the many challenges where new and current researchers can still contribute to the advancement of SDN and further hasten its broadening adoption by network operators.
Abstract: Having gained momentum from its promise of centralized control over distributed network architectures at bargain costs, software-defined Networking (SDN) is an ever-increasing topic of research. SDN offers a simplified means to dynamically control multiple simple switches via a single controller program, which contrasts with current network infrastructures where individual network operators manage network devices individually. Already, SDN has realized some extraordinary use cases outside of academia with companies, such as Google, AT&T, Microsoft, and many others. However, SDN still presents many research and operational challenges for government, industry, and campus networks. Because of these challenges, many SDN solutions have developed in an ad hoc manner that are not easily adopted by other organizations. Hence, this paper seeks to identify some of the many challenges where new and current researchers can still contribute to the advancement of SDN and further hasten its broadening adoption by network operators.

185 citations

Proceedings ArticleDOI
17 Jun 2015
TL;DR: Ravana is introduced, a fault-tolerant SDN controller platform that processes the control messages transactionally and exactly once (at both the controllers and the switches), and maintains these guarantees in the face of both controller and switch crashes.
Abstract: Software-defined networking (SDN) offers greater flexibility than traditional distributed architectures, at the risk of the controller being a single point-of-failure. Unfortunately, existing fault-tolerance techniques, such as replicated state machine, are insufficient to ensure correct network behavior under controller failures. The challenge is that, in addition to the application state of the controllers, the switches maintain hard state that must be handled consistently. Thus, it is necessary to incorporate switch state into the system model to correctly offer a "logically centralized" controller.We introduce Ravana, a fault-tolerant SDN controller platform that processes the control messages transactionally and exactly once (at both the controllers and the switches). Ravana maintains these guarantees in the face of both controller and switch crashes. The key insight in Ravana is that replicated state machines can be extended with lightweight switch-side mechanisms to guarantee correctness, without involving the switches in an elaborate consensus protocol. Our prototype implementation of Ravana enables unmodified controller applications to execute in a fault-tolerant fashion. Experiments show that Ravana achieves high throughput with reasonable overhead, compared to a single controller, with a failover time under 100ms.

145 citations

Proceedings ArticleDOI
02 Apr 2014
TL;DR: Libra is a new tool for verifying forwarding tables in very large networks that runs fast because it can exploit the scaling properties of MapReduce and can take an accurate snapshot of the forwarding state 99.9% of the time, and knows when the snapshot cannot be trusted.
Abstract: Data center networks often have errors in the forwarding tables, causing packets to loop indefinitely, fall into black-holes or simply get dropped before they reach the correct destination. Finding forwarding errors is possible using static analysis, but none of the existing tools scale to a large data center network with thousands of switches and millions of forwarding entries. Worse still, in a large data center network the forwarding state is constantly in flux, which makes it hard to take an accurate snapshot of the state for static analysis.We solve these problems with Libra, a new tool for verifying forwarding tables in very large networks. Libra runs fast because it can exploit the scaling properties of MapReduce. We show how Libra can take an accurate snapshot of the forwarding state 99.9% of the time, and knows when the snapshot cannot be trusted. We show results for Libra analyzing a 10,000 switch network in less than a minute, using 50 servers.

123 citations