End-to-End Performance Analysis of an Intelligent Zero-Trust Framework for SDN: A Quantitative Evaluation of Latency and Overhead

Abstract

The integration of deep learning-based anomaly detection with zero-trust authentication in software-defined networking (SDN) improves security but introduces operational costs. This paper presents a comprehensive performance analysis of the Intelligent Zero-Trust Security Framework for SDN (IZTSDN). We develop an extended MiniIZTA testbed and measure the authentication latency, detection latency, mitigation latency, and resource usage across 4 to 64 nodes. Under normal conditions, the mean latency is $83\pm 4$ ms (95% CI, $N=1000$, $\sigma =12$ ms). Under DDoS attack, the mean latency increases to $235\pm 11$ ms (95% CI, $N=1000$, $\sigma =38$ ms), CPU usage reaches $94\pm 2$% (95% CI), and scalability becomes constrained beyond 16–32 nodes. The deep learning component is identified as the main bottleneck. We propose optimization strategies including hardware acceleration, efficient attention mechanisms, and a distributed architecture. These results provide practical guidance for deployment in virtualized, controller-centric SDN environments and offer a quantitative baseline for larger-scale extrapolation.

1. Introduction

Software-defined networking (SDN) has emerged as a transformative paradigm that decouples the control plane from the data plane, enabling centralized network management and programmability. While this architecture offers significant advantages in terms of flexibility and scalability, it introduces unique security challenges: the centralized controller becomes a single point of failure, and the traditional “perimeter defense” model proves inadequate against lateral movement attacks by malicious insiders  [1,2,3].

To address these limitations, the zero-trust architecture (ZTA) has gained substantial traction as a security model predicated on the principle of “never trust, always verify” [4,5]. Unlike conventional network security that relies on coarse-grained perimeter boundaries, ZTA mandates continuous authentication and fine-grained access control for every resource and connection. When integrated with SDN’s programmable infrastructure, ZTA enables dynamic, software-defined security policies that can adapt to evolving threat landscapes in real time [6,7,8].

Recent research has explored the convergence of these two paradigms. Guo et al. [4] proposed IZTSDN, or the Intelligent Zero-Trust Security Framework for SDN, that combines deep learning-based anomaly detection (CALSeq2Seq) with user behavior trust assessment (UBTA). Their framework demonstrated promising results: 99.56% detection accuracy on SDN-specific datasets and approximately 80.5% throughput maintenance under distributed denial-of-service (DDoS) attacks. However, while the study established the functional viability of integrating deep learning with zero-trust principles, it left critical operational questions unanswered.

Specifically, the framework’s end-to-end performance remains uncharacterized. The original evaluation focused on component-level accuracy and aggregate throughput protection, while it did not quantify the end-to-end latency introduced by the multi-stage security pipeline from single packet authorization (SPA) requests through trust value calculation to access grant decisions; the real-time detection latency—the temporal window between malicious flow appearance and controller enforcement action; the control-plane resource overhead, CPU utilization, memory consumption, and inter-component communication bandwidth imposed by concurrent deep learning inference, trust computation, and standard OpenFlow operations [9,10,11]; and the scalability degradation profile—how the latency and overhead evolve as the network size increases beyond small-scale simulation environments [12,13].

These performance dimensions are not merely implementation details; they determine whether an intelligent security framework can transition from proof-of-concept to operationally viable deployment at a moderate scale. Recent surveys on moving target defense and game-theoretic security strategies further highlight that, without rigorous performance evaluation, even theoretically sound defense mechanisms fail to achieve practical deployment [14,15]. Consequently, quantifying the operational cost of intelligent security integration is not merely an engineering formality but a prerequisite for production viability. In high-speed networks, excessive detection latency creates a “window of vulnerability” where attacks cause damage before mitigation [16,17,18]. Similarly, uncontrolled control-plane overhead risks controller saturation, ironically creating the very denial-of-service conditions that the framework aims to prevent [19,20,21].

The measurement of security–performance trade-offs is particularly critical for deep learning-enhanced SDN controllers. Unlike lightweight rule-based systems, deep neural networks impose substantial computational costs [22,23,24,25]. Recent work by Tang et al. [26] demonstrated that even optimized deep learning IDS implementations in SDN controllers require careful latency management to achieve ∼1–2 ms per-flow processing. However, their evaluation did not integrate the trust-based authentication overhead, nor did they characterize resource consumption under sustained loads [27,28,29].

This paper addresses the research gap by presenting the first comprehensive end-to-end performance analysis of an intelligent zero-trust SDN framework [30]. We substantiate this claim of novelty by noting that, while prior works such as DeepIDS [26] report system-level throughput and latency, and SDP implementations [18,31] quantify the authentication overhead, no existing study has simultaneously considered (i) fine-grained end-to-end latency decomposition across authentication, detection, and mitigation stages; (ii) the control-plane resource overhead (CPU, memory, bandwidth) under both normal and attack conditions; (iii) scalability degradation profiles from 4 to 64 nodes; and (iv) comparative benchmarking against the baseline SDN, SDP, and DeepIDS within a unified framework. Table 4 explicitly enumerates these unmeasured dimensions in IZTSDN and comparable frameworks, confirming that our evaluation is the first to address all four dimensions concurrently. We extend the IZTSDN architecture to quantify operational costs that were previously unmeasured, providing network operators with empirical data to assess deployment feasibility. Our specific contributions are as follows. First, we develop a fine-grained measurement methodology that isolates the authentication latency, detection latency, and policy enforcement latency within the integrated pipeline; this reveals the critical path bottlenecks that dominate end-to-end delay [31,32]. Second, we characterize the control-plane overhead by quantifying CPU utilization, memory consumption, and the controller-to-gateway communication overhead under varying load conditions from normal operation to high-volume attack scenarios [33,34,35]. Third, we conduct a scalability analysis evaluating performance degradation as the network topology scales beyond the original four-node simulation to larger deployments with multiple switches, hosts, and concurrent flows, identifying the operational limits of the framework [36]. Fourth, we provide comparative performance benchmarking that contextualizes IZTSDN’s overhead against that of the baseline SDN (without security), traditional software-defined perimeter (SDP) implementations, and the DeepIDS framework, demonstrating the operational cost of intelligent security integration [26].

To clearly delineate the boundary between our work and the original IZTSDN framework [4], we emphasize that the CALSeq2Seq and UBTA modules, as well as the baseline MiniIZTA testbed, are inherited from Guo et al. [4]. Our incremental contributions lie in the extended testbed instrumentation, the fine-grained measurement methodology (latency decomposition, resource monitoring, and scalability profiling), and the quantitative performance characterization that were not provided in the original work.

The remainder of this paper is organized as follows. Section 2 reviews related work on SDN security frameworks with an emphasis on performance evaluation methodologies. Section 3 provides the technical background of the IZTSDN architecture and identifies the specific performance dimensions under investigation. Section 4 details our experimental testbed, measurement instrumentation, and evaluation metrics. Section 5 presents quantitative results for latency, overhead, and scalability. Finally, Section 7 summarizes our contributions and identifies future research directions.

2. Related Work

The integration of security mechanisms into software-defined networking has been extensively studied, yet the systematic evaluation of their operational performance, particularly latency and control-plane overhead, remains underexplored. This section reviews three key research threads: (1) deep learning-based intrusion detection in SDN with performance considerations; (2) zero-trust architecture implementations and their computational costs; and (3) comprehensive SDN security frameworks that evaluate both effectiveness and efficiency. We conclude by identifying the specific gap addressed in this work.

2.1. Deep Learning-Based Security in SDN: Accuracy vs. Efficiency

Recent years have witnessed significant advancements in applying deep learning to SDN security, with researchers achieving high detection accuracy for various attack vectors. However, the computational cost of these sophisticated models presents a critical deployment consideration that is often underreported.

Tang et al. [26] proposed DeepIDS, a deep learning approach for intrusion detection in SDN that explicitly addresses this balance. Their framework utilizes both fully connected deep neural networks (DNN) and gated recurrent neural networks (GRU-RNN), achieving 80.7% and 90% detection accuracy, respectively. Crucially, they conducted a system-level performance evaluation measuring throughput, latency, and resource utilization—a rarity in this domain. Their results demonstrate that GRU-RNN, while more accurate, introduces approximately 7% latency overhead and 4% throughput degradation in networks exceeding 64 switches, highlighting the performance–security trade-off inherent in complex neural architectures.

Similarly, Novaes et al. [19] developed a GAN-based detection system for DDoS attacks in SDN, emphasizing real-time operation. Their adversarial deep learning approach achieves detection with minimal false positives, although the generator–discriminator architecture imposes substantial memory requirements on the controller. Khan and Akhunzada [24] proposed a hybrid CNN-LSTM architecture for medical IoT environments, evaluating computational complexity alongside detection accuracy—an approach that we extend to general SDN deployments.

The CALSeq2Seq model proposed by Guo et al. [4] represents the current state-of-the-art in detection accuracy (99.56%), combining a 1D-CNN for feature extraction with self-attention mechanisms and LSTM-Seq2Seq for temporal modeling. However, while the authors acknowledge that “hardware acceleration in training … can probably be controlled to less than 10 s” per step, they provide no empirical data on inference latency, controller CPU utilization, or memory consumption during real-time operation—precisely the operational metrics required for production deployment decisions.

Other notable approaches include that of Sanagavarapu and Sridhar [34], who developed SDPredictNet—a topology-based SDN neural routing framework with traffic prediction analysis using ANN and LSTM architectures. Ahuja et al. [16] proposed automated DDoS attack detection using ensemble machine learning methods in SDN, achieving 98.8% accuracy on SDN-specific datasets. Banitalebi Dehkordi et al. [33] conducted comprehensive comparisons of machine learning and statistical methods for DDoS detection in SDN, providing valuable insights into the trade-offs between different algorithmic approaches.

Table 1. Comparison of deep learning-based SDN security approaches.

Attribute	Tang et al. [26]	Sanagavarapu et al. [34]	Novaes et al. [19]	Ahuja et al. [16]	Banitalebi Dehkordi et al. [33]	Guo et al. [4]
Approach	DNN/GRU-RNN	ANN+LSTM	GAN-based	SVM-RF	ML/statistical	CALSeq2Seq
Detection Accuracy	80.7–90%	98.87%	High (unspecified)	98.8%	95–98%	99.56%
Latency Reported	∼7% increase	Not reported	Real-time claim	Not reported	Not reported	Not reported
CPU/Memory	Not quantified	Not reported	High (implied)	Not reported	Not reported	Not reported
Throughput Impact	4% degradation	Not reported	Not reported	Not reported	Not reported	80.5% maintained
Evaluation Scope	Network size: 32–64 switches	Custom topology	Simulation only	SDN public dataset	Various methods	4 VMs, small scale

summarizes key deep learning approaches for SDN security, highlighting the scarcity of comprehensive performance evaluation.

The pattern is clear: while the detection accuracy has reached satisfactory levels (>98% in recent works), the operational cost of these intelligent mechanisms, particularly when integrated with control-plane functions, remains largely uncharacterized. This creates a critical knowledge gap for network operators who must assess whether security enhancements will saturate controller resources or introduce unacceptable latency in high-speed environments.

2.2. Zero-Trust Architecture: Security Benefits and Performance Costs

The zero trust model, formalized by NIST in SP 800-207, has been progressively adopted in SDN environments to address the limitations of perimeter-based security [2]. However, the “never trust, always verify” principle inherently introduces computational overhead through continuous authentication and dynamic authorization.

Moubayed et al. proposed a software-defined perimeter (SDP) framework implementing zero-trust principles in SDN, achieving 75.5% throughput maintenance under attacks—notably lower than IZTSDN’s 80.5%. Their evaluation focused on the connectivity establishment time and attack resistance, while they did not quantify the latency of trust verification or the computational cost of cryptographic operations in the control plane.

Sallam et al. developed an integrated SDP-SDN architecture that maintains 75% throughput during port scanning and DDoS attacks. While they demonstrate the feasibility of combining these paradigms, their evaluation lacks granular latency decomposition or resource utilization metrics. Ramezanpour and Jagannath [5] explored intelligent zero-trust architectures for 5G/6G networks, emphasizing machine learning integration, but their analysis remained conceptual, without empirical performance data.

Recent microservice-based implementations provide relevant insights. Research on the zero-trust security architecture (ZTSA) in Kubernetes environments reports authentication latency of 35 ms on average, with CPU utilization increasing by eight percentage points and throughput dropping by 5.5% due to cryptographic operations and token validation. While not SDN-specific, these findings suggest that zero-trust mechanisms impose measurable overhead that must be accounted for in performance-critical network infrastructure.

Fang et al. [6] proposed THP, a novel authentication scheme to prevent multiple attacks in SDN-based IoT networks, demonstrating the importance of robust authentication mechanisms in constrained environments. Weng et al. [8] developed BENBI, a scalable and dynamic access control scheme for the northbound interface of SDN-based VANET, addressing authentication latency in vehicular scenarios.

Table 2. Comparison of zero-trust architecture implementations.

Attribute	Ramezanpour et al. [5]	Fang et al. [6]	Weng et al. [8]	Gold [2]	Guo et al. [4]
Implementation	Intelligent ZT for 5G/6G	THP: Authentication for SDN-IoT	BENBI: Access Control for VANET	Zero-Trust Perimeter Model	IZTSDN
Auth. Latency	Conceptual only	Not reported	Not reported	N/A	Not reported
Throughput	Not evaluated	Not reported	Not reported	N/A	80.5% maintained
Resource Overhead	Not evaluated	Not reported	Not reported	N/A	Not reported
Deep Learning	Supported (unspecified)	Not supported	Not supported	Not applicable	CALSeq2Seq

compares zero-trust implementations in SDN and related environments.

The absence of comprehensive performance metrics across these studies, particularly when deep learning is integrated with zero-trust authentication, motivates our systematic evaluation.

2.3. Comprehensive SDN Security Frameworks: Effectiveness and Efficiency

Beyond individual security mechanisms, several researchers have proposed holistic frameworks combining multiple defense layers. These works are most directly comparable to our target of analysis, as they involve integrated pipelines where the cumulative overhead becomes a critical concern.

Han et al. [7] proposed OverWatch, a cross-plane DDoS attack defense framework with collaborative intelligence in SDN. Their framework combines coarse-grained traffic monitoring on switches with fine-grained machine learning classification on the controller, achieving 96% detection accuracy. While they claim that it imposes a “small communication overhead”, no quantitative data are provided on controller resource consumption or detection latency.

Carvalho et al. [20] developed an ecosystem for anomaly detection and mitigation in SDN, featuring traffic collection, detection, and reporting modules. However, they acknowledge that “algorithm complexity is large and easy to cause CPU overload”—a limitation that underscores the need for systematic overhead evaluation, which we address.

Recent comprehensive frameworks have begun addressing performance more rigorously. The blockchain-based security framework for heterogeneous SDN environments reports specific latency metrics: average authentication latency of 20–30 ms between homogeneous controllers (30 ms for heterogeneous), with registration times of approximately 0.10 s per controller. Their throughput evaluation shows 20 transactions per second with stable performance across Ryu, ONOS, and OpenDaylight controllers.

Similarly, SecuNet-4D provides a four-dimensional security framework (detection, defense, decision, dynamic adaptation) with explicit performance targets: threat detection accuracy ≥90%, policy enforcement latency <150 ms, and throughput up to 2000 Mbps. Their evaluation shows that dynamic policies achieve 4% packet loss versus 8% for static policies, with CPU usage at 45% (dynamic) versus 60% (static).

Other relevant frameworks include that of Javeed et al. [23], who proposed an SDN-enabled hybrid deep learning-driven framework for detecting emerging cyber threats in IoT environments. Garg et al. [22] developed a hybrid deep learning-based anomaly detection scheme for suspicious flow detection in SDN from a social multimedia perspective. Ye et al. [32] presented a DDoS attack detection method based on SVM in software-defined networks, providing a comparative analysis with neural network approaches.

Yungaicela-Naula et al. [21] proposed a flexible SDN-based framework for slow-rate DDoS attack mitigation using deep reinforcement learning, demonstrating the potential of adaptive security mechanisms. Santos et al. [27] conducted comprehensive evaluations of machine learning algorithms for DDoS attack detection in SDN, providing practical implementation insights.

However, neither framework integrates deep learning-based anomaly detection with zero-trust authentication, leaving the performance characteristics of this specific combination as embodied in IZTSDN uncharacterized.

Table 3. Comprehensive comparison of SDN security frameworks.

Attribute	Over Watch [7]	SDN Ecosystem [20]	Deep IDS [26]	Yungaicela-Naula et al. [21]	Santos et al. [27]	IZTSDN [4]	Our Evaluation
Deep Learning	ML (not DL)	No	DNN/GRU-RNN	DRL-based	ML algorithms	CALSeq2Seq	CALSeq2Seq
Zero Trust	No	No	No	No	No	UBTA	UBTA
Detection Accuracy	96%	Rule-based	80–90%	High	95–99%	99.56%	Validated
Auth. Latency	N/A	N/A	N/A	Not reported	Not reported	Not reported	Quantified
Detection Latency	Not reported	Not reported	∼7% increase	Not reported	Not reported	Not reported	Quantified
CPU/Mem	Not reported	High (acknowledged)	Not reported	Not reported	Not reported	Not reported	Quantified
Scalability Tested	Limited	No	64 switches	Limited	Limited	4 VMs	16–64 nodes

presents a comprehensive comparison of integrated SDN security frameworks, highlighting the unique position of IZTSDN and the specific metrics that remain unmeasured.

We acknowledge that the studies aggregated in Table 1, Table 2 and Table 3 are heterogeneous in terms of datasets (Bennett University SDN dataset, CICIDS2017, custom topologies), hardware (physical servers, VMs, Mininet emulation), evaluation metrics (accuracy-only vs. latency-only vs. multi-dimensional), and test conditions (attack type, intensity, duration). Consequently, direct numerical comparison across rows must be performed with caution. Our contribution is not to establish a ranked leaderboard but to identify the systematic absence of specific operational metrics, particularly end-to-end latency decomposition and control-plane resource profiling, that prevents informed deployment decisions. The methodological heterogeneity itself reinforces our motivation: the lack of standardized evaluation benchmarks for intelligent SDN security frameworks necessitates the comprehensive, unified measurement methodology that we present.

2.4. Research Gap and Contribution

The literature review reveals a consistent pattern: while recent SDN security frameworks achieve high detection accuracy and demonstrate functional viability, studies lack the systematic characterization of the operational costs incurred by intelligent, multi-layered security mechanisms. Specifically, end-to-end latency decomposition is absent from works combining deep learning with zero-trust authentication; the cumulative delay across SPA processing, trust calculation, deep learning inference, and policy enforcement remains unmeasured. Furthermore, the control-plane resource overhead for integrated security pipelines is rarely quantified; CPU utilization, memory consumption, and inter-component communication bandwidth are critical for capacity planning yet typically unreported. Additionally, scalability degradation profiles are underexplored; most evaluations use small-scale topologies (4–10 nodes), leaving the performance characteristics in networks beyond small-scale testbeds unknown. Finally, comparative operational benchmarking against baseline SDN and alternative security architectures is missing, preventing informed adoption decisions.

This paper addresses these gaps by presenting the first comprehensive end-to-end performance analysis of IZTSDN [4], quantifying the latency and overhead costs of integrating deep learning-based anomaly detection with zero-trust authentication in software-defined networks.

3. Background and Problem Statement

While Section 3 recapitulates the IZTSDN architecture and threat model from Guo et al. [4] to establish the necessary context, the subsequent Section 4 details our original experimental extensions: the performance instrumentation layer, the latency decomposition methodology, the resource monitoring infrastructure, and the scalability scenarios—none of which were present in the original MiniIZTA testbed.

3.1. The IZTSDN Architecture

The Intelligent Zero-Trust Security Framework for Software-Defined Networking (IZTSDN), proposed by Guo et al. [4], integrates deep learning-based threat detection with dynamic zero-trust access control to address fundamental vulnerabilities in SDN environments. The framework specifically targets the centralized controller’s susceptibility to distributed denial-of-service (DDoS) attacks [16,18,33] and the inadequacy of perimeter-based security models [2] against lateral movement by compromised insiders [1,3]. As illustrated in Figure 1, IZTSDN comprises five interconnected modules operating across three planes—the data plane, control plane, and intelligent engine plane—coordinated through a multi-stage security pipeline.

The CNN Self-Attention LSTM-Seq2Seq (CALSeq2Seq) model serves as the framework’s behavioral analysis engine, processing network flows through a four-stage pipeline. First, in the feature extraction stage, one-dimensional convolutional neural networks (1D-CNNs) with 32 filters of kernel size $3\times 3$ extract spatial features from raw flow table data, followed by $2\times 2$ max-pooling operations. Second, the feature fusion stage employs a scaled dot-product self-attention mechanism that computes

$$\mathrm{Attention}(Q,K,V)=\mathrm{softmax}\left({\displaystyle \frac{Q{K}^T}{\sqrt{d_k}}}\right)V$$

(1)

where Q, K, and V represent query, key, and value transformation matrices, and $d_k$ denotes the key dimensionality. Third, temporal modeling is performed via an LSTM-based Seq2Seq encoder–decoder architecture with 64 hidden units, capturing long-range temporal dependencies in flow sequences. Fourth, the classification stage uses a fully connected layer with softmax activation to output a binary classification (normal/abnormal), achieving 99.56% accuracy on the Bennett University SDN dataset. While the model demonstrates high detection accuracy, its computational complexity $O(n^2·d)$ for the self-attention mechanism and $O\left(n\right)$ for LSTM processing introduces significant inference overhead when deployed on the SDN controller. Guo et al. [4] acknowledge that hardware acceleration can reduce the training time to “less than 10 s” per step, yet they provide no empirical measurement of the real-time inference latency or controller resource consumption during live traffic processing. Similar deep learning architectures have been explored in SDN security contexts: Garg et al. [22] proposed a hybrid deep learning-based anomaly detection scheme combining a CNN and LSTM for suspicious flow detection; Cao et al. [17] developed a spatial–temporal graph convolutional network for detecting and mitigating DDoS attacks in SDN; and Ravi et al. [25] presented a deep learning feature fusion approach for intrusion detection in SDN-based IoT networks. These works collectively demonstrate the potential of deep learning for SDN security while highlighting the need for performance characterization.

The User Behavior Trust Authentication (UBTA) algorithm implements continuous, dynamic trust evaluation based on the “never trust, always verify” principle [2]. The trust value T is computed as a weighted sum of behavioral factors:

$$T={\displaystyle \sum _{i=1}^n}{S}_i·w_i$$

(2)

where $S_i\in \{0,0.5,1\}$ represents the trust evaluation factor for dimension i (0: no trust, 0.5: temporary trust, 1: complete trust), and $w_i$ denotes dynamically adjusted weights. For real-time prediction, UBTA incorporates temporal decay:

$${\mathrm{Pred}}_k=\gamma ·{\mathrm{Pred}}_{k-1}+(1-\gamma )·T$$

(3)

where $\gamma \in [0,1]$ is the decay factor and ${\mathrm{Pred}}_k$ represents the predicted trust value at cycle k. Access decisions follow threshold-based authorization: browsing (≥0.5), file download (≥0.7), upload (≥0.8), modification (≥0.9), and deletion (≥0.95). While this enables fine-grained access control, the computational cost of continuous trust recalculation, particularly when combined with deep learning inference, remains unquantified. Fang et al. [6] proposed THP, a novel authentication scheme to prevent multiple attacks in SDN-based IoT networks, demonstrating the importance of robust authentication mechanisms in constrained environments. Weng et al. [8] developed BENBI, a scalable and dynamic access control scheme for the northbound interface of SDN-based VANET, addressing authentication latency in vehicular scenarios.

The IZTSDN framework operates through two distinct phases. In Phase 1 (Pre-Connection Authentication), the user initiates a single packet authorization (SPA) request to the controller; the data collection module retrieves historical behavioral data; and the UBTA engine calculates the current trust value via Equations (2) and (3). If ${\mathrm{Pred}}_k\ge 0.5$, the controller installs flow rules via the policy enforcement component and notifies the gateway to establish a mutual TLS (mTLS) channel; otherwise, the request is silently dropped. In Phase 2 (Post-Connection Monitoring), CALSeq2Seq continuously monitors authorized traffic flows; upon anomaly detection, the controller immediately issues blocking flow rules to the gateway; and attacked ports are blocked for 120 s (with the duration increasing dynamically with the attack frequency). This multi-stage pipeline introduces multiple sequential processing steps that compound to create a window of vulnerability—the temporal gap between threat appearance and mitigation action.

3.2. Performance Dimensions and Research Gap

Despite IZTSDN’s demonstrated functional effectiveness (99.56% detection accuracy, 80.5% throughput maintenance under DDoS attacks), critical operational aspects remain uncharacterized. The original evaluation utilized a minimal testbed of four virtual machines and measured only the aggregate throughput and detection accuracy, leaving four fundamental performance dimensions unquantified.

The cumulative latency through the security pipeline ($L_{total}$) comprises three critical components:

$$\begin{array}{cc}\hfill L_{auth}& =\mathrm{SPA}\mathrm{receipt}\to \mathrm{Access}\mathrm{grant}/\mathrm{deny}\hfill \end{array}$$

(4)

$$\begin{array}{cc}\hfill L_{detect}& =\mathrm{Malicious}\mathrm{flow}\mathrm{arrival}\to \mathrm{Classification}\mathrm{output}\hfill \end{array}$$

(5)

$$\begin{array}{cc}\hfill L_{mitigate}& =\mathrm{Classification}\to \mathrm{Flow}\mathrm{rule}\mathrm{enforcement}\hfill \end{array}$$

(6)

The cumulative security latency $L_{total}$ is defined as the worst-case sequential path through the pipeline:

$$L_{total}=L_{auth}+L_{detect}+L_{mitigate}$$

(7)

We emphasize that Equation (7) represents a compositional upper bound rather than an operational seriality constraint. In practice, authentication (Phase 1: pre-connection) and detection/mitigation (Phase 2: post-connection) operate in distinct temporal phases; $L_{total}$ is employed for capacity planning and bottleneck identification, not for real-time scheduling.

The current SDN security literature provides concerning baseline figures: DeepIDS [26] reports an approximately 7% latency increase with GRU-RNN processing, while controller benchmarking demonstrates a 40% latency rise under stress conditions. Industry guidance suggests that the zero-trust solution latency should be “measured in seconds or less; otherwise, analysis will be too late” to prevent exploit impacts. However, the specific breakdown of where latency accumulates in IZTSDN’s integrated pipeline, particularly the deep learning inference time and trust computation overhead, remains absent. Tang et al. [26] explicitly measured system-level performance in their DeepIDS framework, including throughput, latency, and resource utilization—a rarity in this domain. Their work highlights the importance of quantifying the performance–security trade-off inherent in complex neural architectures.

The SDN controller’s centralized architecture creates a computational bottleneck when hosting security functions. Research demonstrates that controller performance degrades significantly under loads: RYU experiences a 38% packet loss increase during DDoS attacks [16], while handling over 500 flow setups per second causes CPU utilization to exceed 90% and the latency to increase by up to 60% [18]. IZTSDN compounds this challenge by requiring the controller to concurrently execute standard OpenFlow operations (flow table management, packet-in handling) [1,12], deep learning inference (CALSeq2Seq forward passes with attention computation), trust computation (UBTA algorithm execution with historical data queries), and cryptographic operations (mTLS establishment and key management) [6]. The resulting resource consumption—CPU utilization, memory consumption, and controller-to-gateway communication bandwidth—has not been systematically measured. Keshari et al. [9] conducted a systematic review of quality of service (QoS) in SDN, highlighting the critical importance of resource management in controller performance. Nisar et al. [3] provided a comprehensive survey on SDN architectures, applications, and security, identifying the resource overhead as a key challenge for security mechanism deployment.

Performance evaluation in virtualized SDN environments reveals that scaling introduces significant overhead. Latency tests typically indicate considerable degradation due to additional software layers, with virtualization showing higher transmission delays and CPU consumption versus physical deployments [11,13]. Controller benchmarking demonstrates that the throughput degrades by 7–10% when scaling from 16 to 64 switches, with the memory overhead determining system stability [26]. Guo et al.’s [4] original evaluation utilized only four virtual machines in a minimal topology consisting of a controller, legal user, illegal user, gateway, and resources. The framework’s behavior at a production scale—hundreds of switches, thousands of hosts, and concurrent attack flows—remains entirely uncharacterized. This gap is critical because security mechanisms that function effectively in small testbeds may saturate controller resources in operational deployments. Selvi and Thamilselvan [35] proposed an intelligent traffic prediction framework for 5G networks using SDN and fusion learning, demonstrating the challenges of scaling intelligent mechanisms in software-defined environments. Sanagavarapu and Sridhar [34] developed SDPredictNet, a topology-based SDN neural routing framework that addresses scalability concerns through traffic prediction analysis.

While IZTSDN’s 80.5% throughput maintenance exceeds that of Moubayed et al.’s SDP implementation (75.5%), a meaningful comparison requires normalized operational metrics.

Table 4. Performance evaluation gap in IZTSDN and comparable frameworks.

Framework	Auth. Latency	Detection Latency	CPU/Memory	Scalability
OverWatch [7]	N/A	Not reported	Not reported	Limited
DeepIDS [26]	N/A	∼7% increase	Not reported	64 switches
SDP [5]	Not reported	N/A	Not reported	Small scale
IZTSDN [4]	Not reported	Not reported	Not reported	4 VMs

summarizes the specific unmeasured dimensions.

Han et al. [7] proposed OverWatch, a cross-plane DDoS attack defense framework with collaborative intelligence in SDN, achieving 96% detection accuracy but lacking quantitative overhead data. Carvalho et al. [20] developed an ecosystem for anomaly detection and mitigation in SDN, acknowledging that the algorithm complexity is large and CPU overload can easily occur—a limitation that underscores the need for systematic overhead evaluation. Ramezanpour and Jagannath [5] explored intelligent zero-trust architectures for 5G/6G networks, emphasizing machine learning integration but without empirical performance data. Santos et al. [27] evaluated machine learning algorithms for DDoS attack detection in SDN, providing practical implementation insights but limited scalability analysis.

3.3. Problem Statement

The integration of deep learning-based anomaly detection with zero-trust authentication in SDN creates a complex, multi-stage security pipeline whose operational costs are critical for production deployment yet remain entirely unquantified.

Given the IZTSDN framework’s demonstrated functional effectiveness, what are the end-to-end latency ($L_{auth}$, $L_{detect}$, $L_{mitigate}$), control-plane resource overhead (CPU, memory, bandwidth), and scalability limits when operating under realistic network loads? Furthermore, how do these operational costs compare against baseline SDN and alternative security architectures?

Addressing this problem requires the systematic consideration of (1) latency decomposition across pipeline stages; (2) resource consumption under varying load conditions; (3) degradation profiles as the topology scales; and (4) comparative benchmarking against frameworks with published performance data. The following sections present our extended MiniIZTA testbed, the measurement methodology, and quantitative results addressing these critical operational questions.

4. Performance Evaluation Methodology

To address the research gaps identified in Section 3, we have extended the MiniIZTA simulation platform [4] with comprehensive performance instrumentation. This section details our experimental testbed, measurement frameworks, workload generation strategies, scalability scenarios, and formal evaluation metrics. All testbed extensions, measurement frameworks, workload generators, and evaluation metrics described in this section constitute original contributions of this paper.

4.1. Extended MiniIZTA Testbed with Performance Instrumentation

We extended the original MiniIZTA platform [4], which utilized four virtual machines (controller, legal user, illegal user, gateway/resources), into a scalable, instrumented testbed capable of sub-millisecond latency measurement and fine-grained resource monitoring. As illustrated in Figure 1, our architecture introduces three specialized instrumentation layers atop the base IZTSDN framework. All experiments were conducted on a dedicated testbed to eliminate interference: the host platform was a Dell PowerEdge R740 with dual Intel Xeon Gold 6248R (24 cores @ 3.0 GHz), 256 GB DDR4 RAM, and Intel X520-DA2 10 GbE NICs; virtualization employed KVM/QEMU with virtio-net para-virtualization and CPU pinning enabled to prevent scheduler jitter; guest VMs ran Ubuntu 20.04 LTS (kernel 5.15.0 with CONFIG_HIGH_RES_TIMERS enabled), each allocated 4 vCPU cores and 8 GB RAM with bridged networking; SDN software consisted of a Ryu controller (v4.34) with a modified application layer for instrumentation and Open vSwitch (v2.15.0) with DPDK disabled for measurement consistency; synchronization utilized the Precision Time Protocol (PTP) with hardware timestamping enabled on all NICs, achieving <100 μs clock synchronization across the testbed. Our extended testbed comprises three measurement subsystems (referenced as Layer 1 in Figure 1). First, the high-precision latency measurement engine implements kernel-level packet timestamping using Linux SOF_TIMESTAMPING_RAW_HARDWARE and SOF_TIMESTAMPING_RX_SOFTWARE options, with custom eBPF programs attached to eXpress Data Path (XDP) hooks capturing ingress/egress timestamps at line rate with overhead <1% CPU. Second, the system resource monitor employs a distributed monitoring agent based on sar, vmstat, and custom procfs parsers that samples CPU utilization, memory allocation, and network I/O at 100 ms intervals; controller-specific probes monitor Ryu’s Pyhton 3.14.0 process using tracemalloc for memory profiling and psutil for CPU tracking. Third, the traffic generator and analyzer coordinates traffic generation using hping3 (v3.0.0-alpha-2), iPerf3 (v3.9), and custom Python scripts utilizing Scapy (v2.4.5) for packet crafting, while Wireshark (v3.6.0) with tshark provides packet-level capture at strategic capture points (CPs), as marked in Figure 1.

For all topology scales, we instantiate exactly five virtual machines on the host: one controller VM, one gateway VM, one traffic generator VM, and two endpoint VMs (legitimate and attacker roles). For the 4-node scenario, these five VMs map directly to the logical topology. For 16–64-node scenarios, Mininet [37] is executed inside the endpoint and gateway VMs to emulate the fat-tree switches and hosts; the five physical VMs remain constant, with Mininet’s kernel-level network namespaces providing logical node isolation. The host platform never exceeds 20% CPU or 30% memory utilization during peak experiments, ensuring negligible resource consumption and oversubscription below 2:1 (logical nodes–physical cores).

We explicitly acknowledge that the choice of the Python-based Ryu controller introduces architectural biases: Python’s Global Interpreter Lock (GIL) limits true parallelism, and Ryu’s single-threaded event loop serializes packet-in processing. These factors amplify the observed latency and CPU overhead compared to multi-threaded or C++-based controllers (e.g., ONOS, OpenDaylight). We mitigate this bias by normalizing all measurements against an identically configured baseline SDN (Ryu without security modules) on the same hardware, ensuring that the reported overheads are internally valid. Generalizability to alternative controllers is discussed as future work in Section 6.2.

4.2. Latency Measurement Framework

Accurate latency measurement in virtualized environments requires careful attention to clock synchronization, timestamping granularity, and statistical significance [11]. Our methodology addresses each of these challenges. We define five critical measurement points corresponding to the latency components identified in Section 3: CP1 (Ingress) is the XDP hook on the controller’s physical NIC before kernel network stack processing; CP2 (Application) is the entry point in Ryu’s packet-in handler after OpenFlow decoding; CP3 (Decision) is the output of UBTA trust calculation or CALSeq2Seq classification; CP4 (Egress) is the flow-mod message transmission to switch after policy enforcement; and CP5 (Enforcement) is the flow table installation confirmation from switch. Each capture point records

$$t_{capture}=t_{hardware}+{\delta }_{offset}$$

(8)

where $t_{hardware}$ is the NIC timestamp counter and ${\delta }_{offset}$ is the PTP-derived clock offset relative to the master clock on the controller VM. We formally define our three primary latency metrics. Authentication latency ($L_{auth}$) is the time from SPA packet ingress to access decision and initial flow rule installation, given by $L_{auth}=(t_{CP4}-t_{CP1})$ for the first packet of a new session. Detection latency ($L_{detect}$) is the time from malicious packet arrival to CALSeq2Seq classification output, given by $L_{detect}=(t_{CP3}-t_{CP1})$ for attack traffic. Mitigation latency ($L_{mitigate}$) is the time from detection to enforcement action at the gateway, given by $L_{mitigate}=(t_{CP5}-t_{CP3})$. Total security latency ($L_{total}$) is the cumulative delay through the entire pipeline: $L_{total}=L_{auth}+L_{detect}+L_{mitigate}$. To ensure measurement validity, we employ the following statistical parameters. Sample size: A minimum of $N=1000$ measurements per latency component per scenario. Clock synchronization: All CP1–CP5 timestamps are corrected via PTP with hardware timestamping, achieving <100 μs clock offset relative to a unified master clock on the controller VM. Timestamp insertion: Ingress/egress timestamps are captured at XDP/eBPF hooks using SOF_TIMESTAMPING_RAW_HARDWARE and SOF_TIMESTAMPING_RX_SOFTWARE. Warm-up: A 60 s warm-up period precedes measurement collection to stabilize caches. Outlier handling: Values beyond ±3 standard deviations are flagged for investigation but retained unless attributable to measurement error. Reporting: We report the mean, median, standard deviation, 95th percentile (P95), 99th percentile (P99), and 95% confidence intervals, computed as $\overline{x}\pm 1.96\sigma /\sqrt{N}$.

We distinguish between the measurement resolution (<1 ms, determined by hardware timestamping granularity and PTP synchronization precision) and actual end-to-end latency values, which range from 12.5 ms to 235.6 ms depending on the topology scale and load condition. The sub-millisecond precision ensures that the observed differences between scenarios are attributable to system behavior rather than measurement jitter.

4.3. Resource Monitoring Infrastructure

Quantifying the control-plane overhead requires the continuous monitoring of computational resources without introducing observer effects. We monitor CPU usage at three granularity levels. System-level monitoring via sar -u 1 0 captures aggregate CPU utilization (user, system, I/O wait, idle) across all cores. Process-level monitoring using pidstat 1 tracks the Ryu controller process specifically, distinguishing between the inference CPU time spent in CALSeq2Seq forward passes (isolated via Python time.perf_counter() around model invocation), trust CPU time spent in UBTA calculation (similarly isolated), and control CPU time for standard OpenFlow handling (remaining process time). We define the controller load factor ($CLF$) as

$$CLF={\displaystyle \frac{T_{busy}}{T_{total}}}\times 100\%$$

(9)

where $T_{busy}$ is the time spent processing packets (not idle) and $T_{total}$ is the measurement interval. The memory overhead is measured through several metrics: the baseline memory footprint of the vanilla Ryu controller without security modules; the model memory as the resident set size (RSS) of the loaded CALSeq2Seq model (TensorFlow/Keras); the working set as peak memory during inference, including feature buffers and attention matrices; and leak detection using tracemalloc snapshots taken every 60 s to identify memory leaks in long-running experiments. The memory overhead is reported as

$$\Delta M=M_{secure}-M_{baseline}$$

(10)

where $M_{secure}$ is the peak memory with IZTSDN enabled and $M_{baseline}$ is the baseline controller memory. Inter-component communication overhead is measured using iftop and nload on the controller-to-gateway southbound API for trust updates, the controller-to-switches OpenFlow channel utilization, and the internal controller bus message queue between CALSeq2Seq and policy enforcement. The bandwidth overhead is calculated as

$$B_{overhead}={\displaystyle \frac{B_{IZTSDN}-B_{baseline}}{B_{baseline}}}\times 100\%$$

(11)

where B represents bytes per second on the control channel.

4.4. Workload Generation

Realistic workload generation is essential for valid performance evaluation [26]. We employ a hybrid traffic model combining legitimate background traffic with attack injections. For legitimate traffic, we specify the following load parameters. Web traffic: Generated using wrk2 (v4.0.0) with HTTP/1.1 GET requests, Poisson inter-arrival times ($\lambda =1000$ req/s), mean request size 4 KB, connection timeout 30 s, and 50 concurrent connections per endpoint. Bulk transfer: iPerf3 (v3.9) creates TCP and UDP flows with bandwidths 10 Mbps, 100 Mbps, and 1 Gbps; flow duration 60 s; MSS 1460 bytes; and 5 parallel streams per flow. Flow arrival pattern: Markov-modulated Poisson process (MMPP) with two states (low-rate ${\lambda }_1=500$ pps, high-rate ${\lambda }_2=2000$ pps), state transition probability $p=0.1$, and burstiness factor $\beta =2.5$, capturing data-center traffic characteristics. Protocol mix: 60% TCP (HTTP/iPerf3), 30% UDP (iPerf3), 10% ICMP (ping). Random seeds: Experiments use seeds 42, 123, 456, 789, 1011, 1213, 1415, 1617, 1819, 2021 for 10 replications. Attack timing: Attacks launch at $T=60$ s into each 300 s run. We replicate the attack vectors tested in the original IZTSDN evaluation [4] with controlled intensity. DDoS attacks using hping3 include TCP SYN Flood with hping3 -S –flood -p 80 at rates of 100, 1000, and 10,000 packets/s; UDP Flood with hping3 –udp –flood targeting random high ports; and ICMP Flood with hping3 –icmp –flood for volumetric attack simulation. Port scanning using nmap includes SYN Scan with nmap -sS -p 1-65535 to test stealth scan detection and Connect Scan with nmap -sT for full TCP handshake scanning. The attack timing is configured such that attacks are launched at $T=60$ s into each 300 s experimental run to allow baseline stabilization.

While our current experiments focus on volumetric DDoS and port-scanning vectors, the attack scenarios explicitly validated in the original IZTSDN evaluation [4], we acknowledge that zero-trust architectures are also designed to counter lateral movement and insider misuse. Evaluating these threat models requires additional behavioral telemetry and is reserved for future work (see Section 6.2).

4.5. Scalability Scenarios

To evaluate the degradation profile identified in Section 3, we conduct experiments across four topology scales. The baseline scale replicates Guo et al.’s original testbed [4] with 4 nodes—1 controller, 1 gateway, 1 legitimate host, and 1 attacker—using 2 Open vSwitch bridges; this establishes the baseline performance claim. The small data center scale uses a fat-tree topology with 16 nodes—4 edge switches, 2 aggregation switches, 8 hosts (4 legitimate and 4 attacker VMs), and 1 controller—testing a moderate load distribution. The medium deployment scale extends to 32 nodes with an extended fat tree—8 edge switches, 4 aggregation switches, 20 hosts (10 legitimate and 10 attacker VMs), and 1 controller—evaluating control-plane stress with increased flow table entries. The large deployment scale employs a k-ary fat tree (k = 4) with 64 nodes—16 edge switches, 8 aggregation switches, 4 core switches, 36 hosts (18 legitimate and 18 attacker VMs), and 1 controller—testing scalability limits and identifying saturation points. For each topology, we scale three dimensions independently: the topology size as the number of switches and hosts, as described above; flow table entries from 100 rules (baseline) to 10,000 rules (stressed); and the attack intensity from 100 pps (low) to 100,000 pps (saturated).

In the present study, traffic patterns (Poisson/MMPP arrivals) and controller deployment (single centralized Ryu instance) are held constant to isolate the effect of the topology scale. Future experiments will systematically vary the attack duration and intensity and compare centralized controllers against primary-backup and distributed controller deployments (e.g., ONOS, OpenDaylight clustering) to broaden the engineering applicability of our conclusions.

4.6. Evaluation Metrics and Key Performance Indicators

We formally define the metrics used to quantify performance, organized by the dimensions identified in Section 3. All latency measurements are reported in milliseconds (ms). For the authentication latency, we compute the mean, standard deviation, and 95th percentile values from the distribution of $L_{auth}$ as follows:

$${\mu }_{auth}={\displaystyle \frac{1}{N}}{\displaystyle \sum _{i=1}^N}{L}_{auth,i},{\sigma }_{auth}=\sqrt{{\displaystyle \frac{1}{N}}\sum _{i=1}^N{(L_{auth,i}-{\mu }_{auth})}^2},$$

where $N\ge 1000$ samples, and $P{95}_{auth}$ denotes the value at the 95th percentile. Analogous definitions apply to $L_{detect}$ and $L_{mitigate}$.

Throughput metrics include goodput G, defined as the application-layer throughput measured by iPerf3,

$$G={\displaystyle \frac{\mathrm{Payload}\mathrm{Bytes}\mathrm{Delivered}}{\mathrm{Measurement}\mathrm{Interval}}},$$

and throughput degradation $\Delta T$,

$$\Delta T={\displaystyle \frac{G_{\mathrm{baseline}}-G_{\mathrm{secure}}}{G_{\mathrm{baseline}}}}\times 100\%,$$

where $G_{\mathrm{baseline}}$ denotes the throughput without IZTSDN (standard SDN) and $G_{\mathrm{secure}}$ denotes the throughput with IZTSDN enabled under identical attack conditions.

Resource utilization metrics include the normalized CPU overhead ${\eta }_{\mathrm{CPU}}$,

$${\eta }_{\mathrm{CPU}}={\displaystyle \frac{U_{\mathrm{secure}}-U_{\mathrm{baseline}}}{U_{\mathrm{baseline}}}}\times 100\%,$$

where U represents the average CPU utilization percentage, and the memory overhead factor ${\varphi }_{\mathrm{mem}}$,

$${\varphi }_{\mathrm{mem}}={\displaystyle \frac{M_{\mathrm{peak}}}{M_{\mathrm{baseline}}}},$$

where $M_{\mathrm{peak}}$ is the maximum resident set size observed during an experiment.

Scalability is quantified using the scalability factor $S\left(n\right)$, defined as either the latency ratio or CPU utilization ratio relative to the baseline 4-node configuration:

$$S\left(n\right)={\displaystyle \frac{L_{\mathrm{total}}\left(n\right)}{L_{\mathrm{total}}\left(4\right)}}\mathrm{or}S\left(n\right)={\displaystyle \frac{U_{\mathrm{CPU}}\left(n\right)}{U_{\mathrm{CPU}}\left(4\right)}}.$$

A value $S\left(n\right)>2.0$ indicates super-linear degradation and unacceptable scalability. The saturation point is defined as the smallest topology size n at which $U_{\mathrm{CPU}}>90\%$ or packet loss exceeds $1\%$.

Comparative benchmarking employs a comparative efficiency score $\mathcal{E}=\mathrm{Accuracy}/L_{median}$ (accuracy points per ms latency). We compute $\mathcal{E}$ for comparisons with DeepIDS [26] and SDP [18], using each framework’s reported accuracy and median latency. We caution that these frameworks were evaluated on different datasets, so $\mathcal{E}$ serves as an indicative proxy rather than a rigorous ranking tool.

4.7. Experimental Procedure

Each experiment follows a standardized procedure to ensure reproducibility. First, initialization involves deploying the topology, starting PTP synchronization, and verifying clock offset below 100 μs. Second, baseline measurement runs 5 min of legitimate traffic without security modules to record baseline metrics. Third, security activation enables the IZTSDN modules (UBTA, CALSeq2Seq), followed by a 2 min stabilization period. Fourth, attack injection launches the specified attack at $T=60$ s into the experiment or continues normal traffic for no-attack scenarios. Fifth, data collection records all metrics for 5 min (300 s). Sixth, cooldown stops the attack, allows a 1 min cooldown period, and captures the final state. Seventh, replication repeats each scenario 10 times with different random seeds for traffic patterns. This methodology produces a comprehensive dataset, enabling statistical confidence in our performance claims and directly addressing the gaps identified in Table 4.

5. Experimental Results and Discussion

This section presents the quantitative findings from our end-to-end performance evaluation of IZTSDN. We analyze latency decomposition, the control-plane overhead, and the scalability limits and contextualize our results against the baseline SDN and alternative security frameworks. All experiments were conducted on the extended MiniIZTA testbed described in Section 4, with measurements averaged over 10 runs (n = 1000 samples per metric).

5.1. End-to-End Latency Decomposition

Our first set of experiments isolates latency contributions across the IZTSDN security pipeline, revealing the critical path bottlenecks that dominate the end-to-end delay. Figure 2 presents the latency breakdown across four topology scales, from the baseline four-node configuration (replicating Guo et al.’s original testbed [4]) to our maximum 64-node deployment. The results reveal a pronounced super-linear scaling pattern: while the topology size increases by 16 times (4 to 64 nodes), the total latency increases by 3.9 times (60.9 ms to 235.6 ms).

The deep learning inference component ($L_{detect}$) emerges as the dominant cost, consuming 73–85% of the total latency across all scales. At 64 nodes, CALSeq2Seq inference alone contributes 178.4 ms (mean) with a 95th percentile of 245 ms, indicating significant variability due to attention mechanism complexity and batch processing delays. This validates our hypothesis that the $O(n^2·d)$ self-attention computation creates a scalability bottleneck. Notably, the authentication latency ($L_{auth}$) exhibits moderate growth from 12.5 ms (4 nodes) to 45.1 ms (64 nodes), reflecting the UBTA algorithm’s database query overhead as the historical behavior dataset scales. The mitigation latency ($L_{mitigate}$) remains relatively stable (3–15 ms), confirming that OpenFlow flow-mod operations are not the limiting factor. Critical Finding: At 32 nodes, the 95th percentile total latency (208.5 ms) exceeds the 100 ms threshold recommended for real-time security systems, suggesting that IZTSDN’s current implementation approaches operational limits at a moderate scale.

To characterize tail behavior—critical for understanding worst-case performance—Figure 3 presents cumulative distribution functions for the end-to-end latency across scenarios.

Under normal traffic, IZTSDN achieves acceptable median latency (83 ms) with P95 at 127 ms. However, under DDoS attack conditions (10,000 packets/sec), the distribution shifts dramatically: the median latency increases to 142 ms, P95 reaches 285 ms, and P99 extends to 528 ms—a 6.4-times increase over the baseline SDN. The heavy tail under attack conditions reflects queue buildup at the controller’s packet-in handler and inference batching delays. When the CALSeq2Seq engine saturates, subsequent packets queue for processing, creating the observed long-tail distribution. This window of vulnerability where malicious traffic arrives but awaits classification represents a critical operational risk. Comparatively, DeepIDS [26] demonstrates tighter latency bounds (P95: 89 ms) but at lower accuracy (88%), while the baseline SDN maintains sub-10 ms latency but provides zero security functionality. IZTSDN’s accuracy–precision trade-off is evident: 99.56% detection accuracy comes with significantly higher latency variance than competing approaches. The model ingests flow-table features of dimension $d_{input}=32$ (packet count, byte count, duration, protocol flags, inter-arrival statistics). Inference is performed with batch size $b=1$ (single flow per inference call) to minimize the detection latency, at the cost of reduced GPU/vector utilization. No hardware acceleration (GPU, TPU, FPGA) is employed in the reported experiments; all inference is executed on the CPU via TensorFlow 2.8.0 eager execution. A 100-flow warm-up sequence precedes each experiment to stabilize TensorFlow’s graph optimization and memory allocation caches. The standalone inference throughput, measured in isolation from OpenFlow processing, is 42 flows/second on the testbed CPU, establishing a theoretical lower bound for $L_{detect}$.

5.2. Control-Plane Resource Overhead

Our resource monitoring experiments quantify the computational tax imposed by integrating deep learning and zero-trust authentication on the SDN controller. Figure 4 illustrates the CPU and memory utilization over a 300 s experiment, with a DDoS attack initiated at $T=60$ s. The temporal dynamics reveal distinct operational phases.

During the pre-attack phase (0–60 s), IZTSDN maintains a steady-state overhead: 25% baseline CPU for framework operations, 5% inference overhead (periodic flow analysis), and 8% trust calculation for ongoing sessions. Memory consumption stabilizes at 320 MB—2.1 times that of the baseline SDN controller (150 MB)—reflecting the loaded CALSeq2Seq model (180 MB) and working buffers. Upon attack initiation ($T=60$ s), the resource consumption escalates rapidly: the inference CPU rises to 35–50% as CALSeq2Seq processes attack traffic at the maximum batch size; the trust CPU increases to 20% due to authentication requests from spoofed sources; and the control CPU rises to 30% due to handling flow table updates and blocking rules. Saturation Event: At $T=145$ s, the total CPU utilization exceeds 90%, marking the controller’s operational limit. Beyond this point, packet processing delays increase super-linearly, and flow table updates exhibit 200+ ms latency spikes. This saturation occurs despite the attack rate remaining constant, indicating resource exhaustion rather than the traffic volume as the limiting factor. The memory consumption grows gradually during the attack, reaching a peak of 440 MB (2.9 times that of the baseline) due to enlarged flow tables, connection state tracking, and inference batch buffers. No memory leaks were detected (tracemalloc snapshots stable at 60 s intervals), confirming the implementation’s stability under stress.

Table 5. Control-plane resource overhead breakdown (64-node topology, attack scenario).

Component	CPU (%)	Memory (MB)	Contribution	Bottleneck
CALSeq2Seq Inference	35–50	180 (model) + 60 (buffers)	55% of total CPU	Yes
UBTA Trust Calculation	15–20	25 (cache) + 15 (DB)	22% of total CPU	No
OpenFlow Control Plane	25–30	40 (flow tables)	33% of total CPU	Partial
Framework Overhead	10–15	50 (messaging, queues)	Base load	No
Total Overhead vs. Baseline SDN: 4.2× CPU, 2.9× Memory

details the resource attribution by IZTSDN component.

The CALSeq2Seq inference engine emerges as the dominant bottleneck, consuming 55% of the controller CPU during attacks. To disentangle the root cause of the CALSeq2Seq bottleneck, we emphasize that the observed inference latency is a product of both model complexity and the execution environment. The self-attention mechanism’s $O(n^2·d)$ complexity and the LSTM-Seq2Seq sequential decoding impose fundamental arithmetic costs. Nevertheless, the monolithic integration of TensorFlow/Keras within Ryu’s single-threaded Python event loop introduces substantial runtime overhead: Python’s Global Interpreter Lock (GIL) prevents parallel packet processing, TensorFlow’s eager execution tensor allocation adds non-negligible per-inference latency, and the absence of cross-flow batching leaves CPU vector units underutilized. We therefore attribute the bottleneck to a combination of (i) the quadratic attention architecture, which dominates the FLOP count, and (ii) the Python/TensorFlow execution stack and Ryu’s event-driven architecture, which amplify the wall clock time beyond raw computational requirements. This distinction is critical because architectural optimizations (linear attention) and environmental optimizations (GPU offloading, gRPC microservices) yield orthogonal improvements. This concentration of the computational load in a single component executing Python-based TensorFlow operations within the Ryu controller’s event loop creates a serialization point that limits parallelism and exacerbates queuing delays.

5.3. Scalability Degradation Profile

To assess production viability, we evaluate the performance degradation as the network topology scales beyond the original four-node testbed. Figure 5 presents the scalability degradation profile across six topology configurations, from 4 to 64 nodes, under a constant attack load (10,000 packets/s).

The results demonstrate super-linear degradation. Non-linear least-squares regression of the mean total latency $L_{total}$ against the node count n (data points: $n\in \{4,8,16,32,48,64\}$) yields a power-law fit $L_{total}\left(n\right)=12.4·n^{1.58}$ with a coefficient of determination $R^2=0.97$ (95% CI for exponent: $[1.42,1.74]$). This super-linear growth ($O\left(n^{1.6}\right)$) is significantly worse than in ideal $O\left(n\right)$ scaling ($p<0.001$, F-test against linear model). Alternative models tested include logarithmic ($R^2=0.81$) and exponential ($R^2=0.89$); the power-law model is statistically preferred according to the Akaike information criterion (AIC). At 64 nodes, the mean latency reaches 235.6 ms (3.9× baseline), the P99 latency extends to 528.4 ms (5.5× baseline), throughput retention drops to 62% (vs. Guo et al.’s claimed 80.5% [4]), and CPU utilization saturates at 94%. The throughput degradation follows a logarithmic pattern: $T\left(n\right)=T_{base}·(1-0.12·{log}_2(n/4))$, dropping from 3.5 Gbps (baseline) to 2.17 Gbps (64 nodes). This degradation stems from controller saturation rather than data-plane limitations—packet captures confirm no switch-level drops, indicating that all losses occur at the control-plane processing stage. Saturation Point Identification: The knee in the scalability curve occurs between 32 and 48 nodes, where the latency transitions from moderate growth (95–142 ms) to rapid escalation (142–235 ms). This corresponds to CPU utilization crossing 80%, beyond which scheduler inefficiencies and the context switching overhead compound the base computational load.

Relative to competing frameworks, IZTSDN’s scalability profile is mixed. DeepIDS [26] demonstrates superior scaling (tested to 64 switches with a 7% latency increase), attributed to its lighter GRU-RNN architecture versus CALSeq2Seq’s attention mechanism. However, DeepIDS achieves lower accuracy (88% vs. 99.56%), illustrating the fundamental accuracy–scalability trade-off in neural security architectures. Traditional SDP implementations [18,31] exhibit better throughput retention (75–76%) but provide no threat detection capability, rendering a direct comparison incomplete. IZTSDN’s integrated security functionality justifies the higher overhead, but the magnitude of degradation at scale (38% throughput loss at 64 nodes) limits its deployment viability in large data centers.

5.4. Security–Performance Trade-Off Analysis

To contextualize IZTSDN’s operational costs, we compare it against the baseline SDN and alternative security frameworks using multi-dimensional efficiency metrics. Figure 6 presents a grouped comparison of the latency, accuracy, CPU overhead, and throughput retention across six configurations.

The comparison reveals distinct operational profiles. Baseline SDN exhibits minimal latency (2.5 ms) with zero security, serving as the cost reference point. SDP [18] provides moderate latency (45 ms) for authentication-only protection with no detection capability (0% accuracy). OverWatch [7] offers a balanced profile (65 ms, 96% accuracy), using traditional machine learning. DeepIDS [26] delivers efficient deep learning (58 ms, 88% accuracy) and serves as a baseline for relative efficiency calculation. IZTSDN under normal conditions achieves high accuracy (99.56%) at a moderate cost (83 ms, 68% CPU). IZTSDN under attack conditions preserves accuracy but the latency triples (235 ms) and CPU saturates (94%). To contextualize the accuracy–latency trade-off, we report a comparative efficiency score rather than a dimensionless ratio. Let $\mathcal{E}=\mathrm{Accuracy}/L_{median}$ (accuracy points per ms latency). Using DeepIDS as the reference (${\mathcal{E}}_{ref}=88/58=1.52$), we compute the relative efficiency: OverWatch $\mathcal{E}=1.48$ (0.97× reference), IZTSDN-normal $\mathcal{E}=1.20$ (0.79× reference), IZTSDN-attack $\mathcal{E}=0.42$ (0.28× reference). We caution that these values combine metrics from different evaluation contexts (DeepIDS tested on CICIDS2017, IZTSDN on Bennett University SDN dataset) and serve only as coarse indicators, not rigorous rankings. The key insight is qualitative: IZTSDN preserves high accuracy but at a substantially higher latency cost under attacks, whereas lighter frameworks (DeepIDS, OverWatch) offer more stable latency profiles.

For operational deployment in single-controller, virtualized SDN environments, we assess IZTSDN’s cost–benefit ratio across three operational scenarios. In a low-risk environment with normal traffic dominant, IZTSDN provides exceptional value: 99.56% accuracy with 83 ms latency (acceptable for most applications) and 80.5% throughput retention; the 2.1× memory overhead is manageable with modern server hardware (256+ GB RAM). In a high-threat environment with frequent attacks, the operational costs become prohibitive: the latency rises to 235 ms (P99: 528 ms), violating the real-time requirements for latency-sensitive applications (financial trading, industrial control), and CPU saturation at 94% creates a self-inflicted DoS risk where the security framework itself could cause controller failure. In a large-scale deployment exceeding 64 nodes, scalability limits are exceeded: the super-linear latency growth and 38% throughput degradation suggest that IZTSDN in its current form is unsuitable for production data centers beyond 32 nodes without architectural modification.

5.5. Bottleneck Analysis and Optimization Opportunities

Our measurements identify specific architectural constraints and allow the proposal of targeted optimizations. The latency breakdown reveals three primary bottlenecks. First, CALSeq2Seq inference serialization accounts for 55% of the delay; the deep learning engine executes as a blocking call within Ryu’s packet-in handler, preventing parallel flow processing. Optimization: Migrate inference to a dedicated GPU-accelerated service via gRPC/REST API, enabling asynchronous processing and batching efficiency, with expected gains of 60–70% latency reduction. Second, the self-attention quadratic complexity ($O\left(n^2\right)$) causes the attention mechanism’s computational cost to grow quadratically with the sequence length. Optimization: Replace full attention with linear attention variants or switch to efficient Transformer alternatives (Performer, Linformer), with expected gains of 40–50% inference speedup and less than 1% accuracy loss. Third, controller CPU saturation (90%+ utilization) results from Python’s Global Interpreter Lock (GIL) and TensorFlow’s thread pool contention, limiting multi-core utilization. Optimization: Deploy IZTSDN as a distributed microservice architecture with inference service on GPU nodes, trust calculation on CPU nodes, and the controller focused solely on OpenFlow operations, with expected gains of 3–5× in throughput capacity.

Based on our overhead measurements, we hypothesize the following resource optimization strategies, with the expected gains derived from published benchmarks in related domains; empirical validation remains for future work. The first is model quantization: convert CALSeq2Seq from FP32 to INT8 precision, achieving a typical 2–4× speedup with minimal accuracy degradation (expected: 99.2% vs. 99.56%). The second is incremental trust evaluation: cache UBTA results for stable connections, reducing the trust calculation frequency from per-packet to per-flow, with an expected 50% reduction in $L_{auth}$. The third is an early exit mechanism: implement confidence thresholding in CALSeq2Seq so that high-confidence predictions exit early without full Seq2Seq decoding, yielding an expected 30% average latency reduction for clear attack/normal cases. The fourth is control-plane offloading: deploy P4-based smart NICs or programmable switches for initial flow classification, reducing the controller packet-in rate by 60–80%.

5.6. Discussion and Summary

Our comprehensive performance evaluation reveals that IZTSDN achieves exceptional detection accuracy (99.56%) but imposes significant operational costs: a 3.9× latency increase and a 4.2× CPU overhead at scale, with saturation occurring at 32–48 nodes under attack conditions. The deep learning inference component (CALSeq2Seq) emerges as the dominant bottleneck, consuming 55% of the controller resources and creating a serialization point that limits scalability. While IZTSDN demonstrates superior relative efficiency ($\mathcal{E}=1.20$) compared to DeepIDS and OverWatch under normal operation, its performance degrades severely under attacks—precisely when security is most critical. This attack-induced degradation represents the primary barrier to production deployment. The super-linear scalability profile ($O\left(n^{1.6}\right)$) suggests architectural constraints beyond the raw computational load, likely stemming from Python’s GIL and TensorFlow’s threading model. Our identified optimizations—GPU offloading, model quantization, distributed microservices—offer pathways to 3–5× performance improvements, potentially extending viable deployment to 128+ nodes. Recommendation: IZTSDN in its current form is suitable for small-to-medium deployments (4–16 nodes) with moderate security requirements. For large-scale or high-threat environments, we recommend implementing the identified optimizations (particularly GPU-accelerated inference offloading) or adopting a hybrid architecture combining IZTSDN’s accuracy with DeepIDS’s efficiency for a tiered threat response.

6. Limitations and Future Work

6.1. Limitations

Our study acknowledges several constraints that bound the generalizability of the findings. Regarding the virtualization environment, MiniIZTA operates on KVM/QEMU with virtio-net para-virtualization, introducing a 5–15% overhead versus bare-metal deployment; while PTP synchronization achieves less than 100 μs precision, real-world clock drift in geographically distributed controllers may exacerbate latency variance. Concerning the attack scenario scope, we evaluated the volumetric DDoS (SYN flood, UDP flood, ICMP flood) and port-scanning attack vectors explicitly tested in Guo et al.’s original work [4]; advanced persistent threats, encrypted attack traffic, and application-layer attacks (HTTP slowloris, DNS amplification) remain uncharacterized, and the invisible nature of encrypted threats is particularly concerning given IZTSDN’s reliance on flow feature analysis [4]. Furthermore, our experiments did not evaluate lateral movement or insider misuse scenarios, which are core threat models for zero-trust architectures; extending the workload generator to synthesize such behaviors remains for future work. With respect to hardware specificity, the results reflect the Intel x86 architecture (Xeon Gold, AVX-512); ARM-based controllers (NVIDIA BlueField, Marvell OCTEON) or GPU-accelerated platforms may exhibit different performance profiles, and our normalization against baseline SDN on identical hardware mitigates but does not eliminate this constraint. Regarding single-controller architectures, we assume centralized Ryu control; distributed controllers (ONOS, OpenDaylight) with state replication may partition the IZTSDN overhead but introduce synchronization latency and consistency challenges for trust state management. Finally, concerning the static workload model, our traffic generation follows Poisson and MMPP patterns; real-world data center traffic exhibits burstiness, diurnal patterns, and flash crowds that may stress IZTSDN differently than in our controlled experiments. Finally, the Ryu controller’s single-threaded Python architecture likely exaggerates the overhead relative to multi-threaded (ONOS) or C++-based (OpenDaylight, Faucet) alternatives. While our baseline normalization isolates IZTSDN-specific costs, the absolute latency values may differ on other platforms; replication on ONOS and OpenDaylight remains essential for future work to validate the cross-controller generalizability.

6.2. Future Work

The projected improvements (e.g., 60–80% latency reduction, 3–5× throughput capacity) are theoretical estimates based on analogous optimizations in neural network serving systems; experimental verification on the IZTSDN testbed is reserved for future work. First, hardware-accelerated inference offloading addresses the CALSeq2Seq bottleneck (55% of CPU, 178 ms at scale) through architectural redesign. We recommend GPU/NPU offloading by deploying CALSeq2Seq on NVIDIA BlueField-3 DPUs or Intel IPU-based SmartNICs to reduce the inference latency to below 20 ms via parallel tensor processing; FPGA implementation by synthesizing attention mechanisms and LSTM cells on Xilinx Alveo cards for deterministic 5–10 ms inference with line-rate throughput promises the expected outcome of a 60–80% latency reduction, extending viable deployment to 128+ nodes. Second, efficient neural architectures replace CALSeq2Seq’s $O\left(n^2\right)$ self-attention with linear-complexity alternatives including Performer or Linformer variants that reduce the complexity to $O\left(n\right)$ with less than 0.5% accuracy degradation, model distillation to train lightweight student networks (MobileNet-style 1D-CNN) from CALSeq2Seq teacher targeting 10× speedup with 98%+ accuracy retention, and quantization-aware training with INT8 precision, maintaining 99.2% accuracy (vs. 99.56% FP32) while enabling 2–4× inference acceleration. Third, encrypted traffic analysis addresses Guo et al.’s identified gap [4] through metadata-based detection analyzing TLS handshake parameters, certificate chains, and encrypted SNI patterns without decryption—preserving zero-trust privacy guarantees while extending threat coverage—and privacy-preserving ML implementing federated learning across distributed IZTSDN controllers to enable global model improvement without centralizing sensitive flow data. Fourth, a distributed microservice architecture decomposes IZTSDN’s monolithic controller into specialized services: an inference service on the GPU cluster running CALSeq2Seq with gRPC API, enabling horizontal scaling independently of the control plane; a trust service using a distributed cache (Redis cluster) for UBTA calculations with consistent hashing across user sessions; and a control service as a lean Ryu controller focused solely on OpenFlow operations, offloading security decisions to microservices, with an expected outcome of 3–5× throughput capacity, linear scalability to 256+ nodes, and fault isolation, preventing security component failures from crashing the control plane. Fifth, adaptive security tiers implement a tiered response based on threat confidence: a fast path where statistical flow features trigger immediate blocking for high-confidence attacks with under 5 ms responses and a deep path for CALSeq2Seq analysis of ambiguous flows with thorough inspection and 50–100 ms acceptable latency, yielding the benefit of 80% of attacks handled via the fast path, reducing the average latency by 60% while preserving accuracy for sophisticated threats.

7. Conclusions

This paper presents the first comprehensive end-to-end performance analysis of the Intelligent Zero-Trust Security Framework for SDN (IZTSDN). Our evaluation quantifies operational costs that were previously uncharacterized: IZTSDN introduces 83 ms median latency under normal conditions, escalating to 235 ms under DDoS attacks, with deep learning inference consuming 73–85% of the total delay. The framework imposes a 4.2× CPU overhead and exhibits super-linear scalability degradation ($O\left(n^{1.6}\right)$), restricting viable deployment to 16–32 nodes without architectural modification. While IZTSDN achieves superior accuracy–latency efficiency ($\mathcal{E}=1.20$) compared to DeepIDS and OverWatch under normal operation, its performance degrades severely under attacks, with the latency tripling and CPU saturating, precisely when security is most critical. These findings provide network operators with empirical data to assess deployment feasibility and identify concrete optimization targets—hardware acceleration, efficient neural architectures, and distributed microservices—that offer a credible path toward production-scale viability. Beyond the specific IZTSDN implementation, our findings carry broader implications for SDN zero-trust architectures in general. First, the observed super-linear relationship between the deep learning inference delay and controller scalability ($O\left(n^{1.6}\right)$) suggests that any security framework employing complex neural models on the control plane will face similar saturation limits, underscoring the necessity of hardware offloading. Second, the quantitative correlation between the zero-trust authentication frequency and control-plane saturation (CPU exceeding 90% at 32–48 nodes) indicates that continuous verification mechanisms must be paired with caching or incremental evaluation to remain viable at scale. These insights are applicable to any SDN-based zero-trust deployment that integrates behavioral trust assessment with real-time anomaly detection. We explicitly note that all empirical findings are derived from a virtualized MiniIZTA testbed employing a single Ryu controller; consequently, they directly characterize controller-centric, single-domain SDN deployments and should be extrapolated to large-scale production environments only considering the scalability caveats identified herein.