INTRODUCTION
1.
Modern networks face growing data demands and latency-sensitive applications. On the other hand, legacy hardware-based infrastructures remain too rigid to adapt efficiently. This inflexibility limits performance in dynamic topologies such as data centers and edge networks, especially as cloud, IoT, and AI workloads emerge [1,2]. The inability to reconfigure or scale rapidly without performance degradation has created a strong need for intelligent and programmable network solutions. Software-Defined Networking (SDN) addresses these challenges by separating control and data planes, enabling centralized programmability via standardized interfaces such as OpenFlow [3,4]. This architecture enhances automation, scalability, and adaptability by allowing networks to respond dynamically to changing traffic demands.
Among SDN controllers, Ryu and ONOS are two of the most recognized and actively maintained platforms. Ryu, written in Python, is valued for its multithreaded design, modularity, and robust OpenFlow implementation [5–7]. ONOS, developed in Java, is engineered for distributed scalability and is designed to ensure resilience and high availability for carrier-grade applications [8]. Several comparative studies have benchmarked SDN controllers such as POX, Ryu, ONOS, Floodlight, and OpenDaylight across linear and small-scale topologies, reporting differences in throughput, delay, packet loss, and control-plane performance; however, systematic evaluation of Ryu and ONOS under different routing strategies and large-scale network conditions remains limited [9–16].
Earlier investigations focused mainly on small-scale or single-controller environments, leaving open questions about how controller architecture interacts with routing logic and the size of the topology. This study specifically targets production-grade platforms, Ryu and ONOS, and evaluates their behavior using both Dijkstra and Multipath routing in scalable Fat-Tree topologies. By doing so, it addresses a clear research gap in architecture-driven performance dependencies in SDN and aims to provide quantitative insights to guide the deployment of high-throughput, low-latency network infrastructure.
While earlier studies mainly examined small or linear topologies and single-controller evaluations, the present research extends SDN benchmarking toward large-scale, hierarchical Fat-Tree architectures and integrates multiple routing algorithms to perform a comprehensive controller–routing–topology interaction analysis. This multidimensional approach helps isolate the architectural impact on key Quality of Service (QoS) metrics and provides a clearer understanding of network performance under scale.
Routing is a primary function of SDN controllers. The Dijkstra algorithm computes deterministic optimal paths suitable for lightly loaded networks [17,18], whereas Multipath routing distributes flows across disjoint paths to balance load and reduce latency [19,20]. Although both algorithms are widely used, their combined influence under different controller architectures has not been extensively studied. Most prior works analyzed controllers or routing schemes individually, leaving the joint effects of controller design, routing logic, and topology scale largely un-quantified [21,22].
Existing benchmarking efforts have also tended to neglect how topology structure influences individual QoS indicators such as throughput, jitter, round-trip time (RTT), and packet loss ratio (PLR).
Many studies report that only aggregate values without isolating how each factor—controller, routing, or topology—affects system performance[23,24]. This limitation prevents deeper analysis of performance dependencies and hinders optimization in scalable, high-reliability SDN environments. Hence, a unified and statistically validated evaluation framework is required to jointly assess these variables.
This study bridges that gap by conducting a controlled comparison of Ryu and ONOS integrated with Dijkstra and Multipath routing algorithms across scalable Fat-Tree topologies ( = 4–10). Using Mininet and iPerf, both TCP and UDP traffic flows are simulated over 100 independent trials per configuration to ensure statistical confidence. Multiple QoS parameters—including throughput, jitter, RTT, and PLR—along with controller-level metrics such as CPU utilization and flow setup time—are quantitatively evaluated. Through a combined examination of architectural, algorithmic, and topological dimensions, this work offers one of the first statistically validated, end-to-end benchmarking analyses of SDN controllers at scale. The findings provide practical guidelines for deploying controller–routing combinations in latency-sensitive and high-throughput network environments.
The primary contributions of this study are summarized below.
1) Introducing a repeatable comparative study of Ryu and ONOS in Dijkstra and Multipath routing in scalable Fat-Tree topologies.
(2) Measuring the QoS and controller-level metrics such as throughput, jitter, RTT, PLR, CPU utilization, flow set-up time, and scalability.
(3) Comparing the performance, resource consumption, and scalability of routing with centralized (Ryu) and distributed (ONOS) architectures; and (4) Providing deployment-focused information on the use of optimum controller-routing settings in practical data center networks.
The remainder of this paper is organized as follows: Section II is the review of relevant work; section III is the description of the method and experimental setup; section IV is the description of routing implementations; section V is the discussion of results and system-level observations; and section VI is the conclusion with the main findings and the future research directions.
RELATED WORK
2.
SDN controllers are the brains of Software-Defined Networking, and they compute optimal paths and maintain network state in real time. Protocols such as OpenFlow decouple the data plane and control plane to facilitate centralized policy control and dynamic path calculation. This paper presents a comparative performance analysis of Dijkstra and Multipath routing using two widely adopted controllers, Ryu and ONOS, over scalable Fat-Tree topologies. The key Quality-of-Service (QoS) metrics analyzed include throughput, latency, packet loss, and jitter.
We now examine previous benchmarking research that discusses these controllers under various performance conditions. Ryu is a lightweight and open-source Python-based controller widely used in research and prototyping. It supports large-scale network control interfaces such as OpenFlow (1.0–1.3), Netconf, and OF-Config. Users often employ Ryu due to its integration with Mininet, its simple API, and its flexibility in developing custom control applications. Its modular architecture makes it particularly suitable for controlled benchmarking using tools such as iPerf under diverse traffic loads.
Koulouras et al. [8] benchmarked Ryu in wireless topologies and demonstrated competitive performance in delay and jitter, while Ma et al. [23] implemented a real-time traffic-monitoring framework. Multipath routing was first implemented on the POX controller in our earlier study [19] and later adapted to Ryu in this work to ensure experimental continuity and improve scalability.
ONOS (Open Network Operating System) is designed for carrier-grade deployment with high scalability and availability. Written in Java, it features a distributed control architecture where multiple controller instances maintain a consistent network state, balance load, and ensure fault tolerance. It provides advanced capabilities such as clustering, intent-based flow control, and dynamic rerouting.
Septian et al. [21] verified ONOS’s strong failover behavior in clustered setups, whereas Nguyen-Ngoc et al. [22] emphasized its selective flow-monitoring support. Rahman et al. [24] and Monika et al. [25] showed that ONOS can sustain stable throughput and dynamically adapt routing under varying traffic conditions using intent-based approaches. Khan and Al-Hadhrami [26] optimized ONOS with service-specific load balancing to improve link utilization and reduce congestion. Continuing this trend, Sharma and Patel [27] reported that multi-controller ONOS deployments significantly reduce response time and enhance resilience under high load. Although this study primarily uses the Ryu controller for Mininet-based emulation because of its modular and script-friendly nature, results from prior ONOS research are referenced to contextualize scalability, fault tolerance, and distributed control. This dual-perspective approach clarifies how architectural design directly influences routing efficiency and overall QoS performance. Although previous investigations provided valuable observations, most focused on a single controller, network type, or limited performance metric. Typical Ryu studies evaluate response latency and flow-installation time, while ONOS analyses address control-plane scalability and fault tolerance. Comparative research involving both controllers under multiple routing schemes and scalable topologies remains rare. This gap leaves uncertainty regarding how algorithmic routing complexity interacts with centralized and distributed control architectures in realistic multi-level Fat-Tree networks. Furthermore, recent studies (2024–2025) have expanded SDN benchmarking across diverse environments. Monir et al. [28] compared several controllers across network functions and confirmed Ryu’s low control-plane latency and stable behavior under moderate load. Bosi et al. [29] presented a detailed survey identifying ONOS as one of the most resilient solutions for dense network environments.
Ali et al. [20] compared tree, linear, and mesh topologies and showed that topology design significantly affects QoS. Ali et al. [30] also examined industrial IoT networks and demonstrated that controller selection is crucial for time-sensitive communication. Singh et al. [31] benchmarked POX and Floodlight in DCell data-center topologies and confirmed the impact of topological complexity on throughput and delay. Li et al. [32] introduced the NBench suite, verifying ONOS’s scalability under concurrent workloads. Ram and Chakraborty [33] analyzed controllers across wired and wireless scenarios, emphasizing the combined effect of topology and routing on overall efficiency.Recent empirical studies further reinforce these observations by evaluating open-source SDN controllers across diverse network topologies and traffic conditions [20,34].Table 1 summarizes major SDN controller benchmarking studies (2021–2025) and highlights their core findings.
The evolution of these works indicates a shift toward multi-dimensional benchmarking that evaluates controllers not only by throughput or delay but also by their adaptability to routing policies, topology size, and workload intensity. Despite this progress, no previous study has jointly analyzed controller architecture (Ryu or ONOS), routing logic (Dijkstra or Multipath), and topology scalability (Fat-Tree = 4–10) in a unified, statistically validated framework. The present research therefore extends the SDN benchmarking paradigm by combining architectural, algorithmic, and topological perspectives within a single reproducible evaluation model. Overall, these collective investigations emphasize the importance of holistic benchmarking and form the basis for this study, which evaluates Ryu and ONOS controllers using Dijkstra and Multipath routing across scalable Fat-Tree networks and delivers experimentally validated insights for large-scale SDN deployments. Overall, these collective investigations emphasize the importance of holistic benchmarking and form the basis for this study, which evaluates Ryu and ONOS controllers using Dijkstra and Multipath routing across scalable Fat-Tree networks and delivers experimentally validated insights for large-scale SDN deployments.
| Study / Year | Controllers Evaluated | Topology / Environment | Key Metrics Analyzed | Main Findings / Insights |
|---|---|---|---|---|
| Koulouras et al., 2023 [8] | Ryu | Wireless mesh | Delay, Jitter | Ryu showed competitive jitter performance under mobility. |
| Ali U., 2024 [20] | Ryu, ONOS, ODL | Tree, Linear, Mesh | Delay, Throughput | Topology type directly affects QoS; ONOS favored for mesh/tree. |
| Rahman et al., 2023 [24] | ONOS, Floodlight, Ryu | Mixed (tree & mesh) | Throughput, Packet Loss | ONOS maintained higher throughput and lower PLR in dense topologies. |
| Monir et al., 2024 [28] | Ryu, Floodlight, ONOS | Functional benchmarking | Control latency, Stability | Ryu lowest control-plane delay; ONOS highest scalability. |
| Bosi et al., 2024 [29] | Multiple (survey) | Various | Latency, Scalability | ONOS identified as most resilient in high-density networks. |
| Singh Ghritlahare et al., 2025 [31] | POX, Floodlight | DCell data-center | Throughput, Latency | Topology complexity influences controller efficiency. |
| Li et al., 2024 [32] | Ryu, ONOS (NBench) | Standardized suite | Mixed QoS metrics | ONOS scalable and consistent throughput under concurrent load. |
| Current Study (2025) | Ryu, ONOS | Fat-Tree ( = 4–10) | Throughput, Jitter, RTT, PLR, CPU | ONOS–Multipath achieves highest QoS and scalability; integrated benchmark. |
METHODOLOGY
3.
This research work provides a systematic performance analysis of Software-Defined Networking (SDN) using two controllers, Ryu and ONOS, with Dijkstra and Multipath routing. The purpose is to study how different controller–routing configurations affect key Quality-of-Service (QoS) parameters under scalable network conditions. Each controller framework included routing logic that allowed both algorithms to make native decisions, ensuring comparable behavior. All experiments were conducted in the Mininet network emulator using the OpenFlow 1.3 protocol. Ryu (written in Python) and ONOS (written in Java) were selected for their modular architecture and wide use in SDN research. In Ryu, Dijkstra and Multipath algorithms were implemented as standalone Python modules, while in ONOS, equivalent logic was deployed using Java-based OSGi bundles (.oar) through its northbound APIs. This integration ensured uniform execution of routing schemes without altering core controller logic.
The Dijkstra algorithm was implemented using a shortest-path computation with time complexity (²), while the Multipath routing algorithm employed a -disjoint path mechanism for concurrent flow distribution and load balancing. Both modules shared identical flow installation and packet handling logic across controllers to maintain fairness during testing. Both controllers operated under the same experimental conditions, including flow-table rules, link parameters, and host-pairing strategies, to maintain experimental parity. The topology used was a Fat-Tree model, which is widely employed in data centers for its hierarchical scalability and balanced link structure.
Each switch–switch and switch–host link was configured with 1 Gbps bandwidth. Inter-switch links used a 2 ms propagation delay, and edge-host links used 1 ms delay, ensuring consistent network conditions across all scenarios. The topology parameter () defines the number of switch ports and thereby determines the network size and connectivity. Configurations with = 4, 6, 8, and 10 were tested, corresponding respectively to 16, 54, 128, and 250 hosts. Network performance was measured using iPerf to generate TCP and UDP traffic across each controller–routing–topology combination. Each configuration was executed for 100 independent trials, and convergence analysis showed that QoS averages stabilized beyond 80 trials with less than 2 % deviation, confirming statistical consistency. Measured metrics included throughput (Mbps), jitter, round-trip time (RTT), packet-loss ratio (PLR), controller CPU utilization, flow-setup time, and scalability limits—the threshold where additional hosts degrade performance. All values are reported as mean ± standard deviation, with 95 % confidence intervals confirming significance.
Statistical Analysis
3.1.
Each configuration (controller × routing × topology) was executed for 100 independent trials. Paired -tests were used to compare routing algorithms within the same controller, and one-way ANOVA was applied to evaluate differences across topology scales ( = 4–10). The Holm–Bonferroni correction ( = 0.05) was applied to control multiple comparisons. Effect sizes (Cohen’s and ²) were calculated to quantify the magnitude of performance differences. Preliminary variance analysis confirmed that 100 trials achieved less than 5 % relative standard error for throughput at ≥ 8, validating the chosen sample size for statistical confidence.
Reproducibility and Artifact
3.2.
To ensure transparency and replicability, the complete experimental framework, scripts, and datasets have been preserved in a version-controlled private repository. The package includes:
(i) Mininet topology builder scripts for ∈ {4, 6, 8,10};
(ii) controller launch scripts for Ryu v4.34 and ONOS v2.7 with runtime configurations;
(iii) traffic matrices and host-pairing files (uniform random and fixed hotspot models);
(iv) fixed random seeds (seed = 2025) used to generate traffic and flow pairs; and
(v) Jupyter notebooks for reproducing tables and figures.
All experiments were executed in Mininet 2.3 with Open vSwitch 2.17 on Ubuntu 22.04 LTS, using an Intel Core i7-12700 (12 cores, 32 GB RAM) workstation. Background processes were disabled, and CPU cores were pinned using Linux affinity tools to prevent external interference. The provided script run_all.sh automates the entire experimental pipeline—from controller initialization to traffic generation and result logging—and reproduces all figures and tables reported in this paper. The repository is available upon reasonable request to the corresponding author for academic and non-commercial purposes.
This setup enabled a clear assessment of how each controller–routing configuration responded to varying network loads. System performance was monitored using Mininet logs and iPerf outputs, and results were visualized in Matplotlib.Figure 2 depicts the overall experimental workflow.
ROUTING ALGORITHMS
4.
This This section describes the two routing strategies evaluated in this study—Dijkstra’s shortest-path algorithm and a DFS-based multipath algorithm—and their implementation across both Ryu and ONOS SDN controllers. The goal is to assess how each controller handles routing logic, path computation, and flow management under different routing paradigms. A controller-neutral pseudocode is included for Dijkstra’s algorithm to illustrate the core logic, Where the Multipath logic is adapted from prior implementations with necessary architectural modifications explained in context.Both algorithms were implemented with identical input parameters and evaluated under the same topology and traffic conditions to ensure fair comparison of controller–routing behaviors in terms of latency, throughput, and adaptability.
Dijkstra’s Implementation: Ryu vs. ONOS
4.1.
Ryu Implementation
4.1.1.
Dijkstra’s algorithm was implemented in Ryu using its modular, Python-based framework. The controller computes the shortest path between two nodes through the minimum_distance() function and installs flow entries using the ofproto_v1_3 OpenFlow API. Host-to-switch mappings are obtained via helper functions such as get_topology_data() and get_path(). Thepseudocode 1 and controller-specific modules are included in the preserved experimental framework described in Section 3.2 to allow reproduction of routing behavior and flow-installation logic.
Pseudo code 1
Dijkstra’s – RYU/ONOS
1. Initialize switches, MAC table, and adjacency
2. Function get_shortest_path(src, dst):
a. Set distance[src] = 0, others = ∞
b. previous[] = None for all switches
c. unvisited = set of all switches
3. While unvisited is not empty:
a. Select switch u with minimum distance
b. Remove u from unvisited
c. For each neighbor v of u:
- If link exists:
- cost = distance[u] + ink_weight(u, v)
- If cost < distance[v]:
• Update distance[v]
• Set previous[v] = u
4.Reconstruct path from dst to src using previous []
5.Add port information for each switch in the path
6. Return full path with port mappings
Ryu’s flexibility allows customized path computation and runtime flow modification, which facilitates rapid prototyping of routing schemes. However, this also requires manual management of flow states, which can increase complexity in large-scale networks. The Dijkstra algorithm’s computational complexity is (²), acceptable for emulated environments but increasingly demanding for real deployments.
ONOS Implementation
4.1.2.
ONOS provides a distributed, Java-based architecture that includes built-in path computation and topology discovery services. Dijkstra’s logic is accessed through the PathService.getPaths() API, which retrieves all available paths between devices, while flow installation is handled via high-level abstractions such as PointToPointIntent in the IntentService.
When topology changes occur, ONOS automatically regenerates intents to reroute traffic, offering dynamic failover and improved scalability. This architecture reduces developer overhead while maintaining consistency and reliability through its distributed control plane. The effective complexity of ONOS’s Dijkstra implementation is (²) for dense graphs and ( + log ) when optimized with priority queues.
Multipath Algorithm
4.2.
Multipath routing enhances network performance by utilizing multiple feasible paths between a source and destination. Unlike Dijkstra’s single-path approach, it distributes traffic across disjoint routes to improve load balancing, bandwidth utilization, and fault tolerance.
In this study, a Depth-First Search (DFS)–based multipath discovery algorithm from our prior work [19] is extended for both Ryu and ONOS. The core logic performs DFS traversal to enumerate all valid paths, evaluates them using a link-cost function (bandwidth, delay, and utilization), and selects the route with minimum cost as the primary path. Remaining feasible routes are retained as failover options.
Pseudo code 2
Multipath –Ryu/ONOS
1. get_paths(src, dst):
Perform depth-first traversal to find all feasible paths
2. get_path_cost(path):
Calculate total cost based on link weights derived from bandwidth
3. get_optimal_paths(src, dst):
Rank available paths by cost and filter the most efficient ones
4. add_ports_to_paths(paths, first_port, last_port):
Map input/output ports for each hop in the selected paths
The overall complexity of the DFS-based multipath algorithm is ( + ) for path discovery, plus ( log ) for path ranking. This makes it efficient for load-balanced and resilient routing in large-scale SDN topologies such as Fat-Tree.
Pseudo Code 2 illustrates the implementation logic of the Multipath Routing Algorithm as adapted for both Ryu and ONOS controllers, detailing path discovery, cost evaluation, optimal path selection, and port mapping for flow rule installation.
Ryu Implementation
4.2.1.
Ryu’s multipath implementation sits atop its modular control framework and is written in Python. The mechanism first uses a depth-first search algorithm we wrote to discover every candidate path, and then it ranks them according to a bandwidth-centric cost. Once the winning path is determined, the controller emits FlowMod messages to each switch, installing the rules according to the OpenFlow standard. Ryu handles rerouting reactively by listening for packet-in messages and link-down notifications to trigger flow updates.
ONOS Implementation
4.2.2.
ONOS leverages its distributed services for multipath routing. Candidate routes are gathered using PathService.getPaths() and ranked by a tunable LinkWeight function based on link metrics such as bandwidth or delay. Flow deployment uses either multiple PathIntents or the FlowObjectiveService for granular control. ONOS supports both reactive and proactive rerouting, adjusting flow rules automatically when link conditions or topology states change.
While the underlying DFS logic remains consistent, ONOS’s intent-driven model automates flow distribution and failover management, contrasting Ryu’s manually programmed but fine-grained control. This comparison highlights Overall, the two algorithms complement each other in exposing architectural strengths: Dijkstra’s deterministic single-path control highlights per-flow decision latency, whereas the DFS-based Multipath strategy emphasizes parallelism and resilience under congestion or link failures. Their joint evaluation across Ryu and ONOS provides a balanced basis for analyzing control-plane responsiveness and data-plane efficiency in the subsequent Results section.
Experimental Environment and Reproducibility
5.
All experiments were performed under the same setup described in Section 3, using Ubuntu 20.04.4 LTS, Mininet 2.3.0, and OpenFlow 1.3. The Ryu (v4.34) and ONOS (v2.7.0) controllers were connected to the emulated data plane through Open vSwitch 2.5.4.Table 2 summarizes the software and hardware configuration.
Four Fat-Tree configurations ( = 4, 6, 8, 10) were evaluated to analyze scalability. Each controller executed its respective routing mechanisms (Dijkstra and Multipath) exactly as defined in Section 4.
Traffic was generated using iPerf 2.0.13, simulating TCP and UDP flows between randomized host pairs. Key Quality-of-Service (QoS) metrics—throughput, jitter, round-trip time (RTT), and packet-loss ratio (PLR)—were monitored along with controller CPU and memory utilization to assess efficiency.
All trials followed the same reproducibility and statistical framework introduced earlier (100 independent runs, fixed random seeds, 95 % confidence intervals). Results are presented as mean ± SD to ensure consistency and comparability.
Topology Design and Routing Strategy Setup
5.1.
This study analyzed the impact of routing strategies and controller design on SDN performance using the Fat-Tree topology, selected for its hierarchical structure, scalability, and support for equal-cost multipathing—attributes ideal for data-center experimentation. Four topology variants ( = 4, 6, 8, 10) were evaluated to capture scalability effects.
Fat-Tree Topology Construction and Emulation
5.1.1.
The Fat-Tree consists of three hierarchical layers (core, aggregation, and edge), as shown inFigure 3. The parameter determines the number of switches and hosts:
• = 4: 16 hosts, 20 switches
• = 6: 54 hosts, 45 switches
• = 8: 128 hosts, 80 switches
• = 10: 250 hosts, 125 switches
Topologies were programmatically generated with custom Python scripts in Mininet, ensuring deterministic deployment. MiniEdit was used only for initial design validation; all experiments were executed through script-driven automation integrated with controller APIs. Note: These host and switch counts correspond to the theoretical Fat-Tree structure. Controller-level scalability values reported later (e.g., 800 for Ryu and 1,024 for ONOS at = 10) refer to the maximum number of end-hosts each controller can stably manage during emulation.
Controller Architecture and Execution Workflow
5.1.2.
Two synchronized environments were employed:
Network emulator: The Fat-Tree topology ran in Mininet, enabling real-time packet forwarding and iPerf-based traffic generation.
Controller environment: The Ryu or ONOS controller executed the routing logic—either Dijkstra for shortest paths or Multipath for load balancing.
For Ryu, a Python module interacted with the OpenFlow interface to compute and install flow entries dynamically. ONOS operated as a background service, where a custom Java application used northbound APIs and the Intent framework to compute optimal routes and deploy flow rules. This modular setup simplified debugging and supported real-time performance monitoring across all runs.
Performance Evaluation Strategy
5.1.3.
A metric-centric and problem-driven evaluation framework was adopted to avoid generic performance reporting. For each controller–routing–topology configuration, the analysis focused on the most influential Quality of Service (QoS) metric—for example, latency under low-bandwidth conditions or packet loss during high-throughput scenarios.
This approach able to identify configuration-specific performance bottlenecks also Provides practical guidance for selecting optimal controller–routing combinations; and Interprets observed network behavior in relation to real-world SDN challenges such as load balancing, delay sensitivity, and fault tolerance. The framework enables evidence-based interpretation of SDN performance trends by isolating the effects of controller architecture (Ryu vs. ONOS), routing algorithm (Dijkstra vs. Multipath), and topology scale (). This supports informed decisions for optimizing network infrastructure design and scalability.
Performance Measurement
6.
This section presents a wide comparison of quality-of-service performance metrics for Ryu and ONOS SDN controllers. Mainly focusing on key indicators such as throughput, round-trip time, jitter, packet loss rate (PLR), CPU utilization, flow setup time, and scalability. We conducted our evaluations using a Fat-Tree topology with core-switch count parameters of = 8 and = 10, representing medium- and large-scale data center scenarios, respectively. Each metric was computed over 100 simulation episodes and reported as mean ± standard deviation (SD) to represent both central tendency and variability. Results highlight how controller design and routing strategy impact overall network efficiency and responsiveness.
Throughput Analysis
6.1.
Throughput represents the rate at which data is successfully transmitted across the network and serves as a key indicator of overall system performance.
UDP Throughput Across Topology Scales
6.1.1.
To evaluate how routing strategies scale with network size, we measured UDP throughput across four Fat-Tree topologies with core switch parameter values = 4, 6, 8, and 10. We simulated each combination of controller (Ryu or ONOS) and routing algorithm (Dijkstra or Multipath) over 100 independent episodes. Although we collected detailed results for every episode, presenting all of them would be excessive and redundant. To maintain clarity and readability, we report only the average throughput values computed across the 100 episodes. The results demonstrate a consistent performance advantage for Multipath routing across all topology sizes. Among the tested configurations, ONOS–Multipath achieves the highest average UDP throughput—especially at larger scales ( = 8 and = 10)—owing to its distributed architecture and efficient path computation.
Ryu–Multipath also shows strong performance; however, its throughput gain begins to plateau at = 10, suggesting that Ryu’s event-driven processing model may struggle to scale under heavier network loads.
In contrast, Dijkstra-based routing shows lower and more gradual improvements with increasing topology size. This reinforces the known constraint of static shortest-path routing in high-traffic or complex environments, where dynamic path selection becomes crucial for maximizing throughput.
Table 3 summarizes the mean UDP throughput values, whileFigure 4 provides a visual representation of the same data with error bars indicating the standard deviation (±SD) across 100 runs. The inclusion of error bars reflects the variability and stability of throughput measurements, confirming the statistical reliability and repeatability of the results.
= 10, ONOS-Multipath achieved a 33 % higher average UDP throughput (1.467 Mbps) compared to Ryu-Dijkstra (1.101 Mbps; < 0.05), demonstrating the improved scalability and load-balancing capability of the distributed controller architecture.
TCP Throughput across Topology Scales
6.1.2.
Using the same simulation model as in the UDP analysis, TCP throughput was tested across all scales of the Fat-Tree topology ( = 4, 6, 8, 10) and controller routing configurations. The findings demonstrate a consistent performance advantage for Multipath routing over Dijkstra in every tested scenario.
ONOS-Multipath had the best throughput of 4.374 Gbps at the largest scale ( = 10), showing it had the best capacity to deal with the congestion-sensitive nature of TCP in large and complex topologies. Ryu-Multipath also demonstrated good performance with 3.478 Gbps, indicating that Ryu’s event-driven model can still support high throughput despite the single-threaded nature of its architecture. The distributed control plane of ONOS gives a definite scalability benefit, especially in the case of Dijkstra-based routing with increasing topology complexity. For example, with = 8, Ryu-Dijkstra could only achieve 1.21 Gbps, highlighting the weakness of shortest-path routing in the presence of congestion and dynamic traffic trends. These results highlight the advantages of adaptive, multipath-aware routing algorithms, especially when combined with distributed SDN platforms such as ONOS.
InTable 4, we see the average TCP throughput values along with the standard deviation (SD) for different Fat-Tree configurations (from = 4 to = 10).Figure 5 illustrates these findings, with error bars indicating the ± SD from 100 runs. The minimal variations we've noted highlight the reliability and consistency of our experiments. Additionally, by including the SD and error bars, we're showing that our results are statistically significant and trustworthy, with a significance level ( < 0.05) confirmed through a paired -test. At = 10, ONOS-Multipath achieved 150 % higher TCP throughput (4.374 Gbps) compared to Ryu-Dijkstra (1.749 Gbps; < 0.01; Cohen’s ≈ 2.1), confirming the scalability advantage of distributed control and multipath routing in larger topologies.
Jitter Across Topology Scales
6.1.3.
Fat-Tree topologies with = 4, 6, 8, and 10 were used to measure jitter to determine the effect of various controller-routing layouts on traffic smoothness. The average jitter with standard deviation (SD) is summarized inTable 6, andFigure 6 shows these results, with error bars indicating the mean ± SD across 100 experimental runs. The error bars indicate consistency in measurement and statistical reliability ( < 0.05, paired -test). In all configurations, Multipath routing significantly reduced jitter relative to Dijkstra-based routing, demonstrating that adaptive load-balancing schemes reduce the variation in packet delivery delay. The minimum jitter was consistently achieved by ONOS-Multipath, especially at = 8 and = 10, indicating the advantages of ONOS's distributed control plane and the effectiveness of path management. On the other hand, RyuDijkstra was also slightly more prone to jitter variance because it is a centralized, event-driven model that may become a bottleneck under heavy traffic. Small SD values indicate high reproducibility and consistent controller performance across different topologies at each experiment. ONOS-Multipath reduced average jitter by 46% compared with Ryu-Dijkstra (² = 0.31), confirming enhanced temporal stability in packet delivery.
The results inTable 5 are the mean and standard deviation (SD) of PLR across all Fat-Tree configurations, andFigure 6 plots the results with error bars representing ±SD from 100 simulation runs. The low SDs verify the repeatability and consistency of the experiment. In general, these results support the idea that adaptive, load-sensitive routing (especially ONOS multipath routing) guarantees enhanced reliability and delivery quality at a larger network scale. At = 10, the packet-loss ratio decreased from 1.12% (Ryu-Dijkstra) to 0.19% (ONOS-Multipath)—an 83% reduction, attributable to adaptive multipath forwarding and distributed flow management.
Round-Trip Time (RTT) Across Topology Scales
6.1.5.
Round-Trip Time (RTT) was considered one of the basic latency measures to determine the responsiveness of every controller routing layout among Fat-Tree topologies ( = 4, 6, 8, and 10). All scenarios were repeated 100 times, and the average RTT was computed with its standard deviation (±SD) to ensure statistical reliability. Multipath routing always delivered low RTT values, irrespective of the topology scale. ONOS-Multipath has the lowest latency of 1.921 ms at = 10 across all configurations, demonstrating the synergy between adaptive routing and the distributed control plane. Ryu-Multipath was also competitive in latency but had a slightly higher RTT due to its single-threaded, event-driven design.
Conversely, Dijkstra-based routing, especially under the Ryu controller, exhibited high RTT values that increased with network size. Ryu-Dijkstra had the maximum delay (4.710 ms) at = 10, which was not very scalable and did not adapt to changes in traffic conditions. Although ONOS-Dijkstra worked rather well given ONOS's distributed architecture, it lagged behind multi-path settings.
Table 6 shows the mean and standard deviation (SD) of the RTT values for each Fat-Tree configuration, andFigure 7 displays them with error bars representing ±SD from 100 repetitions. Low SD values indicate the repeatability and consistency of the results. Adaptive routing is more beneficial in larger-scale topologies, where the dynamism of path selection and load balancing are vital to minimizing latency. In summary, these results verify that Multipath routing, and in particular its implementation in ONOS, offers better end-to-end responsiveness and scalability for data-center SDN.
The usefulness of adaptive routing is more pronounced in larger topologies, where dynamic path selection and load balancing are essential for reducing latency. The low values of SD between configurations ensure the same and reproducible performance trends. These results support the hypothesis that Multipath routing, especially in the context of ONOS, offers the most optimal end-to-end responsiveness and creates a scalable, stable architecture for data-center-level SDN systems. ONOS-Multipath reduced average RTT by 59% (1.92 ms vs. 4.71 ms; < 0.05), showing faster path convergence and lower queuing delay under large-scale topologies. Overall, quantitative comparisons confirm that ONOS-Multipath consistently achieves the best QoS outcomes, improving throughput by up to 150% and reducing delay metrics (jitter, PLR, RTT) by 40–80% across scales ( < 0.05).
Quality of Service Analysis
7.
This section summarizes the results of all controller–topology scales and controller–routing configurations in terms of Quality of Service (QoS). The analysis clearly shows that Multipath routing, especially when deployed with the ONOS controller, consistently provides the most balanced and superior performance across all evaluated metrics. ONOS-Multipath achieves the highest average TCP throughput (3.476 Gbps) and the lowest average jitter (0.021 ms), packet-loss ratio (PLR) (1.043 %), and round-trip time (RTT) (1.978 ms) among all tested configurations. As shown inTable 7 and plotted asFigure 8.
These findings affirm that ONOS’s distributed control-plane architecture, composed of multiple coordinated instances, enables parallel decision-making, global state awareness, and efficient load balancing. This structural advantage allows ONOS to maintain network stability and scalability even under high-density Fat-Tree topologies.
Ryu-Multipath also demonstrates strong throughput performance, although its jitter values are slightly higher. This is expected because Ryu uses a single-threaded, event-driven processing model, which queues flow setups sequentially and can cause minor delays under heavy or bursty traffic.
Dijkstra-based routing, by contrast, exhibits lower throughput and higher latency, particularly under Ryu, due to its static single-path computation that cannot adapt to transient congestion or varying link conditions. ONOS-Dijkstra shows moderate improvement due to its distributed control logic but still remains less efficient than its multipath counterpart. Advantage of Distributed Control: The clustered architecture of ONOS distributes the computation across multiple controller instances, minimizing flow setup latency and removing single-point bottlenecks. Adaptive Routing Synergy: Multipath routing leverages ONOS's global network view to dynamically rebalance traffic, avoiding congestion and maintaining high throughput under load. Centralized Limit on Controller: Ryu's single-threaded control loop imposes constraints on concurrent decision-making.
Though it works well on a small topology, it becomes less efficient on large networks. Practical Relevance: Such results directly apply to data-center, cloud, and 5G-edge deployments with low latency and high reliability, as well as to adaptive flow management.
Generally, this combined quality of service study confirms that ONOS-Multipath is the most stable, scalable, and high-performance SDN setup, which can serve as a viable guide for choosing controllers and routing policies in a real-world deployment.
System-Level Observations
7.1.
System-level parameters, CPU utilization, flow setup time, and scalability were analysed to supplement the Quality-of-Service (QoS) analysis across all Fat-Tree topologies ( = 4, 6, 8, 10) as shown in Table 10. These measurements provide more insight into each controller's ability to handle growing network complexity and operational load.
Both Ryu and ONOS exhibit expected increases in CPU usage and flow-setup time as the network grows, due to increased workload from routing and control-plane activities. Nevertheless, ONOS continues to exhibit reduced CPU usage and setup times across all topologies, indicative of resource efficiency.
The latter can be attributed to ONOS's distributed, multi-instance control plane, which supports parallel processing and reduces contention among routing tasks. On a large scale ( = 10), ONOS has a 12 percent lower CPU load and has quicker flow establishment (2.0 ms vs 2.4 ms) than Ryu. These benefits directly translate into better responsiveness and reduced delay in flow provisioning, which is vital in production-scale networks to achieve real-time responsiveness. Scalability results support this trend: ONOS can support up to 1,024 hosts at = 10, whereas Ryu scales to only 800 hosts. As shown inTable 8.
Such divergence implies that the single-threaded event loop used by Ryu cannot readily scale to parallel topology changes and flow installations as network size increases. Conversely, the clustered nature of ONOS distributes state management and decision-making, ensuring consistent performance even as load and link density increase. Combined with the previous system-level analysis, these system-level findings are consistent with the previous QoS analysis: ONOS has distributed control, which offers scalability over time, faster responsiveness, and balanced utilization.
The Ryu, though efficient in small to medium-sized networks, shows increasing control overhead with heavier loads. Generally, ONOS provides a resilient, scalable platform for large-scale, high-throughput SDN systems, including data centers and edge computing environments. It is possible to explain why ONOS-Multipath dominates all metrics by the integrated benefits of its distributed control-plane architecture and multipath-sensitive routing intelligence. In contrast to Ryu, where flow requests are handled sequentially in a single-threaded, event-driven loop, ONOS partitions distribute the workload across instances of controllers in a cluster. Such distributed coordination reduces contention when simultaneous flow configurations are used and increases control-plane performance when load is heavy. This advantage is further enhanced by Multipath routing, which uses ONOS's global network state to redistribute flows over multiple disjoint paths. Such synergy minimises congestion hotspots, balances link utilisation, and improves end-to-end latency. Such features are especially useful in high-density data center fabrics, cloud spine-leaf layouts, and 5G edge environments, where low latency and high throughput are important. Therefore, ONOS-Multipath is the configuration most deployment-ready to provide scalable, resilient SDN infrastructure.
Conclusion
8.
The paper tested the execution of Ryu and ONOS controllers with Dijkstra and Multipath routing algorithms on scalable fat-tree networks ( = 4 -10). Quality-of-Service (quality of service) outcomes are obviously the best proof that Multipath routing is much better than Dijkstra, regardless of the settings, and ONOS-Multipath is the one that delivers the best TCP throughput (3.476 Gbps), lowest percentage of packet-loss (1.042%), and less jitter (0.022 ms) at = 10. Competitive results were also achieved by Ryu–Multipath, confirming the ability of path diversity to enhance traffic distribution and delivery stability. Analysis at the system level also made ONOS the more efficient and scalable controller. In all topologies, ONOS consistently had lower CPU usage, shorter flow-setup durations, and better host scalability—up to 1,024 hosts at = 10 and 800 hosts at the same time in Ryu.
These results confirm that the distributed architecture in ONOS is a more effective way to handle growing network complexity as compared to a single-threaded control design, as in Ryu. In general, the ONOS-Multipath setup proves to be the most efficient and balanced, providing high throughput, low latency, efficient resource utilization, and high scalability for large-scale SDN deployments. In the future, the research will examine trade-offs between performance gains and resource consumption to develop more comprehensive deployment frameworks. Future extensions include AI-based adaptive routing, synchronization of multiple controllers, and energy-aware, safe route optimization, moving SDN towards a predictive, self-optimizing networking model.