[Paper Review] Hydra: Leveraging Functional Slicing for Efficient Distributed SDN Controllers

Yiyang Chang, Ashkan Rezaei+4 more|arXiv (Cornell University)|Sep 23, 2016

Software-Defined Networks and 5G13 references3 citations

TL;DR

Hydra proposes a hybrid controller partitioning framework that combines topological and functional slicing to improve scalability and responsiveness in distributed SDN controllers. By isolating latency-sensitive and real-time applications from compute-intensive workloads across partitions, Hydra reduces convergence time, maintains low response latency, and eliminates missed deadlines for real-time applications.

ABSTRACT

The conventional approach to scaling Software Defined Networking (SDN) controllers today is to partition switches based on network topology, with each partition being controlled by a single physical controller, running all SDN applications. However, topological partitioning is limited by the fact that (i) performance of latency-sensitive (e.g., monitoring) SDN applications associated with a given partition may be impacted by co-located compute-intensive (e.g., route computation) applications; (ii) simultaneously achieving low convergence time and response times might be challenging; and (iii) communication between instances of an application across partitions may increase latencies. To tackle these issues, in this paper, we explore functional slicing, a complementary approach to scaling, where multiple SDN applications belonging to the same topological partition may be placed in physically distinct servers. We present Hydra, a framework for distributed SDN controllers based on functional slicing. Hydra chooses partitions based on convergence time as the primary metric, but places application instances across partitions in a manner that keeps response times low while considering communication between applications of a partition, and instances of an application across partitions. Evaluations using the Floodlight controller show the importance and effectiveness of Hydra in simultaneously keeping convergence times on failures small, while sustaining higher throughput per partition and ensuring responsiveness to latency-sensitive applications.

Motivation & Objective

• Address the limitations of topological slicing in SDN controllers, where co-locating diverse applications leads to performance degradation due to resource contention.
• Improve scalability and responsiveness in large-scale SDN deployments by decoupling control-plane functions across servers based on application characteristics.
• Minimize convergence time during network failures while maintaining low response times for latency-sensitive and real-time applications.
• Enable communication-aware placement of applications across partitions to reduce inter-instance communication overhead.
• Provide a flexible, hybrid partitioning model that supports administrative constraints and dynamic load changes.

Proposed method

• Introduce functional slicing as a complementary approach to topological slicing, allowing different SDN applications within the same network partition to be hosted on separate physical servers.
• Formulate a placement optimization problem that prioritizes convergence time as the primary metric, while constraining response times and communication costs.
• Model inter-application communication patterns and use them to guide placement decisions, minimizing cross-partition communication latency.
• Implement a controller placement strategy that isolates computationally intensive applications (e.g., DJ for path computation) from real-time (e.g., heart-beat) and latency-sensitive (e.g., path lookup) applications.
• Integrate prioritization mechanisms to ensure real-time applications meet their deadlines, even under load spikes.
• Evaluate the framework using the Floodlight controller with real-world SDN application workloads, measuring convergence time, response latency, and deadline adherence.

Experimental results

Research questions

• RQ1 Can functional slicing improve convergence time and response latency in distributed SDN controllers compared to traditional topological slicing?
• RQ2 To what extent does isolating compute-intensive applications from real-time and latency-sensitive applications reduce performance degradation?
• RQ3 How does communication-aware placement across partitions affect overall controller responsiveness and scalability?
• RQ4 What is the impact of prioritization on real-time application latency and deadline adherence in a shared controller environment?
• RQ5 How does functional slicing enable better load balancing and administrative flexibility compared to purely topological partitioning?

Key findings

• Hydra reduces the 95th percentile heart-beat latency to approximately 10 ms, compared to 30 ms under topological slicing, eliminating missed deadlines (0% missed vs. 3% under topological slicing).
• With a heart-beat frequency of 10 per second, Hydra ensures all heart-beat messages meet the 100 ms deadline, while topological slicing misses about 3% of deadlines.
• When heart-beat frequency increases to 100 per second, prioritized real-time applications in Hydra achieve timely responses, whereas non-prioritized versions suffer delays of up to 1800 ms.
• Functional slicing isolates latency-sensitive applications (e.g., path lookup, firewall) from load spikes caused by computationally intensive tasks like shortest-path computation.
• The framework sustains higher throughput per partition while maintaining low convergence times and low response latencies across diverse application types.
• Prioritization of real-time applications over latency-sensitive ones significantly improves timeliness, demonstrating that functional slicing alone is insufficient without scheduling discipline.