Problem
Research questions and friction points this paper is trying to address.
Software-Defined Networking
Moving Target Defense
Controller Runtime
Control Plane Performance
Benchmarking
Resource versus Responsiveness: Benchmarking SDN Controller Runtimes for a Moving-Target-Defense Control Plane at Scale
🤖 AI Summary
This study addresses the frequently overlooked role of SDN controller runtimes in Moving Target Defense (MTD), which significantly constrains the performance trade-off between address shuffling and flow table installation. We port CPAM logic to Ryu, OpenDaylight, and ONOS, quantitatively evaluating their resource overhead and responsiveness in a 500-node network based on RFC 8456 benchmarks. Our findings reveal that controller selection constitutes a first-order design decision for MTD: ONOS achieves low latency with minimal CPU utilization, whereas Ryu exhibits a small memory footprint but incurs a hundredfold increase in round-trip time, while all three maintain near-zero packet loss. This work provides the first systematic quantification of runtime-specific performance trade-offs, offering critical empirical evidence to guide controller deployment in MTD architectures.
📝 Abstract
Network Moving Target Defense (MTD) built on Software-Defined Networking (SDN) continuously rotates host-facing addresses to invalidate an attacker's reconnaissance. Each rotation creates a burst of control-plane mutations, while new connections may simultaneously require reactive flow installation. Yet SDN controller runtime is usually treated as an implementation detail in the MTD literature. We show that it materially affects performance. We port the same Continuity-Preserving Address Mutation (CPAM) logic to three widely used controllers: Ryu (single-threaded cooperative Python), OpenDaylight, and ONOS (both multi-threaded JVM), and evaluate them on an identical 500-host campus fabric using an RFC 8456-aligned methodology with ten runs per controller. All three provide near-zero loss, sub-millisecond jitter, and preserve established sessions, but their control-plane behavior differs sharply. OpenDaylight and ONOS keep reactive latency low and stable, whereas Ryu serializes reactive flow installation behind periodic rotation work, increasing reactive RTT by about 100x and causing a small number of setup-time failures. Ryu uses far less memory, while ONOS achieves OpenDaylight-class reactive latency with the lowest CPU utilization of the three and a smaller live heap than OpenDaylight. These results expose distinct resource-versus-responsiveness operating points and show that controller selection should be treated as a first-class design decision in SDN-based MTD.
Innovation
Methods, ideas, or system contributions that make the work stand out.
Moving Target Defense
SDN Controller Benchmarking
Address Mutation
Control Plane Performance
Resource-Responsiveness Tradeoff
🔎 Similar Papers
No similar papers found.
