Paper deep dive
From Simulation to Deep Learning: Survey on Network Performance Modeling Approaches
Carlos GĂźemes-Palau, Miquel Ferriol-GalmĂŠs, Jordi Paillisse-Vilanova, Pere Barlet-Ros, Albert Cabellos-Aparicio
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 96%
Last extracted: 3/31/2026, 2:44:27 AM
Summary
This paper provides a comprehensive survey of network performance modeling approaches for wired networks, tracing the evolution from traditional analytical methods like Queuing Theory and Network Calculus to Discrete Event Simulation (DES) and the recent paradigm shift toward Machine Learning and Deep Learning models. It defines a taxonomy of these approaches, discusses current trends such as the dominance of GNNs and hybrid models, and identifies future research directions including the integration of analytical models with DL and improved simulation scalability.
Entities (5)
Relation Signals (3)
Hybrid Approaches â integrates â Machine Learning
confidence 95% ¡ Researchers began integrating ML to existing approaches to leverage their complementary strengths.
Discrete Event Simulation â evolvedinto â Parallel Discrete Event Simulation
confidence 90% ¡ The development of parallelizable DES (PDES) became a prominent research area.
Machine Learning â replaced â Analytical Models
confidence 90% ¡ DL models have increasingly outperformed them in practice, providing higher accuracy at similar or lower computational costs. As a result, DL-based models quickly became the dominant approach.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Network performance modeling is a field that predates early computer networks and the beginning of the Internet. It aims to predict the traffic performance of packet flows in a given network. Its applications range from network planning and troubleshooting to feeding information to network controllers for configuration optimization. Traditional network performance modeling has relied heavily on Discrete Event Simulation (DES) and analytical methods grounded in mathematical theories such as Queuing Theory and Network Calculus. However, as of late, we have observed a paradigm shift, with attempts to obtain efficient Parallel DES, the surge of Machine Learning models, and their integration with other methodologies in hybrid approaches. This has resulted in a great variety of modeling approaches, each with its strengths and often tailored to specific scenarios or requirements. In this paper, we comprehensively survey the relevant network performance modeling approaches for wired networks over the last decades. With this understanding, we also define a taxonomy of approaches, summarizing our understanding of the state-of-the-art and how both technology and the concerns of the research community evolve over time. Finally, we also consider how these models are evaluated, how their different nature results in different evaluation requirements and goals, and how this may complicate their comparison.
Tags
Links
- Source: https://arxiv.org/abs/2603.28394v1
- Canonical: https://arxiv.org/abs/2603.28394v1
Trouble viewing inline? Open PDF directly â
Full Text
178,983 characters extracted from source content.
Expand or collapse full text
From Simulation to Deep Learning: Survey on Network Performance Modeling Approaches Carlos GĂźemes-Palau, Miquel Ferriol-GalmĂŠs, Jordi Paillisse-Vilanova, Pere Barlet-Ros, Albert Cabellos-Aparicio Universitat Politècnica de Catalunya (UPC), Barcelona, Catalonia, Spain Abstract Network performance modeling is a field that predates early computer net- works and the beginning of the Internet. It aims to predict the traffic perfor- mance of packet flows in a given network. Its applications range from network planning and troubleshooting to feeding information to network controllers for configuration optimization. Traditional network performance modeling has relied heavily on Discrete Event Simulation (DES) and analytical meth- ods grounded in mathematical theories such as Queuing Theory and Network Calculus. However, as of late, we have observed a paradigm shift, with at- tempts to obtain efficient Parallel DES, the surge of Machine Learning mod- els, and their integration with other methodologies in hybrid approaches. This has resulted in a great variety of modeling approaches, each with its strengths and often tailored to specific scenarios or requirements. In this pa- per, we comprehensively survey the relevant network performance modeling approaches for wired networks over the last decades. With this understand- ing, we also define a taxonomy of approaches, summarizing our understand- ing of the state-of-the-art and how both technology and the concerns of the research community evolve over time. Finally, we also consider how these models are evaluated, how their different nature results in different evalua- tion requirements and goals, and how this may complicate their comparison. Keywords: network modeling, network performance, network simulation, analytical models, machine learning, deep learning Email address: carlos.guemes@upc.edu (Carlos GĂźemes-Palau) arXiv:2603.28394v1 [cs.NI] 30 Mar 2026 Contents 1 Introduction3 1.1 Methodology and scope . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Describing Network Models . . . . . . . . . . . . . . . . . . . 7 1.3 Survey Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.4 Structure of Survey . . . . . . . . . . . . . . . . . . . . . . . . 9 2 Taxonomy of Network Performance Models9 3 Network Simulation13 3.1 Discrete Event Simulation . . . . . . . . . . . . . . . . . . . . 13 3.2 Parallel Discrete Event Simulation . . . . . . . . . . . . . . . . 17 3.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4 Analytical Models20 4.1 Queuing Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2 Fluid Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3 Network Calculus . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.1 Algebraic-based Discrete Network Calculus (ADNC) . . 29 4.3.2 Optimization-based Discrete Network Calculus (ODNC) 30 4.3.3 Stochastic Network Calculus (SNC) . . . . . . . . . . . 30 4.4 Other Analytical Models . . . . . . . . . . . . . . . . . . . . . 31 4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5 Machine Learning Models32 5.1 âShallow" ML Models . . . . . . . . . . . . . . . . . . . . . . . 32 5.2 Deep Learning and Graph Neural Networks . . . . . . . . . . 38 5.2.1 RouteNet and Successors . . . . . . . . . . . . . . . . . 38 5.2.2 Other GNN Models . . . . . . . . . . . . . . . . . . . . 40 5.2.3 Other DL Models . . . . . . . . . . . . . . . . . . . . . 43 5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6 Hybrid Approaches45 6.1 Model-tuned Emulation for Performance Modeling . . . . . . . 45 6.2 ML + Analytical Hybrid Models . . . . . . . . . . . . . . . . . 48 6.3 Accelerated DES . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.4 Simulation with DL-Enhanced Accuracy . . . . . . . . . . . . 51 6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2 7 Discussion on Identified Trends and Challenges within Net- work Performance Modeling52 7.1 Balance Between Accuracy, Resolution, Applicability, and In- ference Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7.2 The Dominance of DES and the Surge of GNNs . . . . . . . . 54 7.3 Reduced Interest in Analytical Models . . . . . . . . . . . . . 55 7.4 Adapting to Changing Networks . . . . . . . . . . . . . . . . . 56 7.5 Simulation-Dominated Evaluation . . . . . . . . . . . . . . . . 57 7.6 Heterogeneous Approaches, Heterogeneous Evaluations . . . . 59 8 Future Directions and Opportunities60 8.1 Consolidation of PDES and GNNs Models . . . . . . . . . . . 60 8.2 Analytical Models Enhancing DL Models . . . . . . . . . . . . 61 8.3 ML as a New Tool for Evolving Networks . . . . . . . . . . . . 61 8.4 Data Center-Centric Designs . . . . . . . . . . . . . . . . . . . 62 8.5 Better Usage of Simulation Data for Training Real-World Models 63 9 Conclusions63 1. Introduction Performance modeling has long been a fundamental tool in computer networking. By enabling the prediction and evaluation of network behavior without requiring disruptive changes in live systems, models support network design, planning, and protocol development. From early backbone networks to modern cloud infrastructures, performance models have helped operators make informed, data-driven decisions about scalability, reliability, and effi- ciency. In the research community, much of the focus over the past two decades has been on wireless networks, driven by the rapid rise of mobile communi- cation, 5G/6G technologies, and the Internet of Things. Wired networks, by contrast, seemed comparatively static: their role was often limited to large national backbones such as GBN [1] or Abilene [2], and for a time, modeling research in this area stagnated. However, this perception dramatically changed with the rise of data cen- ters. Once motivated mainly by cloud computing and large-scale web ser- vices, todayâs data centers are increasingly driven by artificial intelligence (AI) and large language model (LLM) training workloads. According to the 3 International Energy Agency [3], conventional servers increased their energy demand from 145 TWh in 2020 to 195 TWh in 2024, with projections ex- ceeding 300 TWh by 2030. Accelerated servers designed for AI workloads project even steeper growth, increasing from 10 TWh in 2020 to 60 TWh in 2024, and are similarly expected to surpass 300 TWh by 2030. These figures illustrate the unprecedented demands on wired networks, particularly data center networks, and the reason why modeling them has become an urgent research priority. Unlike domains such as electromagnetism or fluid dynamics, where gov- erning equations capture system behavior, computer networks lack a single set of exact mathematical laws. Their discrete nature, combined with in- ternet trafficâs bursty and self-correlated behavior [4, 5] and the complexity of congestion control makes accurate modeling a continuous challenge. As networks evolve, so do modeling approaches, from formula-based analytical models and packet-level discrete event simulation to, more recently, machine learningâdriven prediction. From the 1990s to the 2010s, most network performance models were based on analytical modeling or simulation. Analytical models, such as those built on Queuing Theory (QT) [6], described networks as systems of equa- tions. While computationally efficient, they often rely on simplified assump- tions about traffic and service distributions. Network Calculus (NC) [7, 8], alternatively, offered deterministic worst-case performance bounds without assuming specific traffic or service distributions. However, its bounds were often overly conservative and limited to feedforward topologies. Conversely, Discrete Event Simulation (DES) became popular by offering high-fidelity, packet-level modeling of networks. Yet, its computational cost, proportional to the number of network events, made it impractical for large-scale and high-speed networks. While each approach had its strengths, neither fully met the growing demands for scalability, expressiveness, and accuracy. After a period of stagnation in the 2010s, research in network performance modeling was revitalized by the rise of Machine Learning (ML). Although the first applications of ML to network modeling date back to 2001, it was the surge of Deep Learning (DL) models in 2018 that brought a significant breakthrough. These models proved capable of accurately predicting net- work performance while being relatively inexpensive to train and run. This marked a major shift away from traditional analytical models. Although an- alytical approaches provide theoretical guarantees, DL models have increas- ingly outperformed them in practice, providing higher accuracy at similar 4 19901991-20002001-20052006-20102011-20152016-20202021-2025 Year 0 10 20 30 Number of Models SimulationAnalytical ModelsML ModelsHybrid Approaches Figure 1: Identified models per year of publication and type. Does not consider other types of publications, such as surveys. If the same model is covered in multiple papers, it is counted once in the year of its earliest publication. or even lower computational costs. As a result, DL-based models quickly became the dominant approach in the literature. Beyond replacing earlier techniques, DL also inspired a second paradigm shift: the emergence of hy- brid approaches. Researchers began integrating ML to existing approaches to leverage their complementary strengths. For instance, ML models have been incorporated into DES frameworks to reduce simulation time without sacrificing detail or expressiveness. This trend is reflected in Figure 1, which shows the number of network performance models published over the past decades. Research activity peaked in the late 1990s and early 2000s, followed by a period of stagna- tion around 2010. However, since 2018, the field has experienced a strong resurgence, with ML-based models becoming the dominant approach. The figure also shows the steady rise of hybrid methods and a decline in the use of traditional analytical models. In contrast, the number of simulation- based models has remained relatively stable. Although simulation remains a reliable and expressive modeling tool, recent research has shifted toward improving its scalability and execution speed. In this survey, we study the evolution of network performance models over time. We analyze the motivations behind each shift, the limitations that shaped subsequent approaches, and the emerging trends in the latest generation of models. Additionally, we highlight the challenges the field currently faces and the directions research is taking to address them. While surveys exist in related areas, such as wireless networks [9, 10, 11] or specific modeling approaches like NC [12, 13] and Graph Neural Networks [14], to the best of our knowledge, there has not been a dedicated survey that revisits 5 performance modeling with a focus on wired networks. 1.1. Methodology and scope To find all relevant models published in the state-of-the-art (from now on referred to as SotA), we searched within IEEE Xplore, ACMâs Digital Library, and Elvisierâs ScienceDirect for papers with either the terms ânetwork mod- eling" or ânetwork performance". We focused on papers published within the IEEE INFOCOM, IEEE NOMS, IEEE/ACM Transactions on Networking, ACM SIGCOMM, ACM CoNEXT, Elsevier Computer Networks, and Else- vier Computer Communications conferences and journals. We then excluded papers that fell outside the scope of the survey and papers that lacked a network model capable of predicting performance metrics. For certain high- impact papers, such as [15, 16, 17, 18], we also reviewed articles that cite them. For older methods, such as the original QT models, we started by searching in the references of the papers we had already found, and then repeated this process recursively until finding their original precursor. This survey limits itself to models capable of replicating or predicting the performance of traffic flows within wired networks. While there are similar research fields, ultimately, the solutions they encompass attempt to solve differently-natured problems, rendering their comparison fruitless. This ap- plies to the following fields: ⢠Wireless and mobile networks: The methodologies for modeling wired and wireless networks vary significantly due to their differences. Hence, in this survey, we focus only on wired networks, and we refer the interested reader to existing surveys on wireless networks [9, 10, 11]. ⢠Network verification: Rather than predicting network behavior un- der specific conditions, these models focus on ensuring the viability of potential network configurations (e.g., if certain QoS guarantees are maintained [19, 20]). ⢠Traffic prediction models: Unlike network modeling, whose task is to predict the performance of traffic flows within the network, in traffic prediction, the task is to predict and describe the incoming traffic flows. ⢠Anomaly detection: These models are tasked with detecting anoma- lous patterns that can be indicative of a network security threat. Rather than making predictions, they discriminate between the ânormal" ex- pected behaviors and the potentially dangerous unexpected ones. 6 1.2. Describing Network Models Throughout the survey, we will summarize the identified models in tables. In the following section, we describe how we identify models: Model Type Specific type of model (e.g., if simulation, type of simulator; if ML model, which ML architecture...). Input Scope Refers to the scope of the input data of the model: ⢠Single-flow scenarios: models can only model single flows. They do not consider cross-traffic interactions. They also ignore the underlying network topology, or only consider individual links or devices. ⢠Traffic-matrix scenarios: models consider cross-traffic interactions. All flows are explicitly represented, even if the model produces predictions for just a subset of them. However, they still heavily simplify or ignore the underlying network topology. ⢠Full network scenarios: models consider cross-traffic interactions, and also consider the networkâs topology, routing, and characteristics in their calculations. Output Scope Refers to the scope of the predicted performance metrics: ⢠Flow-level: average performance metrics for each flow. ⢠Flow-level with temporal component: like before, but with a tempo- ral component. Methods may vary in the coarseness of the temporal component or how time is aggregated. ⢠Packet-level: can predict individual packets. Supported Traffic Types ⢠UDP: Traffic without congestion control. ⢠TCP: Traffic regulated by congestion control. Some models may con- sider a generic congestion control algorithm; others consider one or multiple versions of TCP. 7 ⢠Non-specific: The model does not specify which traffic distributions it supports. However, because of the nature of how they model traffic distributions, this may result in varying degrees of error depending on the packet arrival time distribution (e.g., queue models modeling traffic through a Poisson process) ⢠Any: can support faithfully any traffic type. Supported Performance Metrics These usually depend on the output scope and traffic type supported by the network model: ⢠Models with packet-level predictions usually predict the full packet in- formation (i.e., the timestamp of the packet at each point of its routing path) ⢠Models for UDP traffic focus on packet delay, jitter, and loss rates. ⢠Models for TCP traffic may also focus on flow completion time (FCT), throughput, and packet round-trip time (RTT). Evaluation Most network models are evaluated or offer theoretical guarantees. If they are, we categorize evaluation in the following manner: ⢠Analytical evaluation: properties are analyzed from an analytical view- point only (i.e., verified through formal proofs). Common in analytical models. Restricted to assumptions made by the analysis itself. ⢠Simulated data evaluation: The model was evaluated using simulated data against the simulatorâs ground truth. ⢠Testbed data evaluation: The model was evaluated using data gener- ated and captured from a testbed network. ⢠Real data evaluation: The model was evaluated using captured real internet data. 8 1.3. Survey Outcomes The main contributions of this survey are as follows: ⢠We introduce a taxonomy for describing the different kinds of network performance models, allowing us to better understand the SotA and how the various approaches influence and complement each other. ⢠We perform a comprehensive study of the relevant network performance models present in the SotA. ⢠We discuss the trends and limitations of the current SotA of net- work performance modeling, comparing them to those identified by researchers back at the start of the millennium. 1.4. Structure of Survey For ease of reading, we summarize the structure of the survey. We also include a summary of the acronyms used throughout the survey in Table 1. ⢠In Section 2 we introduce and describe our taxonomy for network per- formance models. ⢠In the main body of the paper, we survey the current or previously relevant network performance models. Specifically, Section 3 covers network simulators, Section 4 analytical models, Section 5 ML models, and Section 6 hybrid approaches. ⢠Section 7 includes our discussion of the SotA of network performance models. ⢠Finally, in Section 8 we discuss future directions of research into net- work performance models. 2. Taxonomy of Network Performance Models The evolution of network performance models is summarized in Figure 2. This taxonomy shows the four main types of network models, simulation, analytical models, ML models, and hybrid approaches, and how they interact. The earliest network performance models were analytical, based on Queu- ing Theory (QT) [6]. These models describe the behavior of packets in de- vices through systems of queues, based on given assumptions (e.g., packet 9 Acronym Description ADNC Algebraic-based Deterministic Network Calculus AI Artificial Intelligence AQM Active Queue Management CVAE Conditional Variational Auto-Encoder [P]DES [Parallel] Discrete Event Simulation DCQCN Data Center Quantized Congestion Notification [21] DL Deep Learning DNN Dense Neural Network EVT Extreme Value Theory FCT Flow Completion Time FIFO First-In First-Out GCN Graph Convolutional Network [22] GGNN Gated Graph Neural Network [23] GNN Graph Neural Network [24] IPG Inter-Packet Gap LLM Large Language Model LP Logical Process LPP Linear Programming Problem [Bi]LSTM [Bidirectional] Long Short-Term Memory [25] [EW]MA [Exponentially Weighted] Moving Average ML Machine Learning MPNN Message-Passing Neural Network [26] NC Network Calculus NP Neural Processes [27] ns[-2âĽ-3] The Network Simulator [28, 29] ODE (System of) Ordinary Differential Equations ODNC Optimization-based Deterministic Network Calculus PBOO Pay Bursts Only Once [30] PDE (System of) Partial Differential Equations PMOO Pay Multiplexing Only Once [31] QoS Quality of Service QT Queuing Theory RBFNN Radial Basis Function Neural Network RED Random Early Detection RF Random Forest RGCN Relational Graph Convolutional Network [32] RNN Recurrent Neural Network RON Resilient Overlay Networks [33] 10 RON Resilient Overlay Networks [33] RTT Round Trip Time SDE (System of) Stochastic Differential Equations SFA Separate Flow Analysis [30] SNC Stochastic Network Calculus SVR Support Vector Regression [DC]TCP [Data Center [34]] Transmission Control Protocol TFA Total Flow Analysis [7, 8] TMA Tandem Matching Analysis [35] UDP User Datagram Protocol Table 1: List of acronyms arrival distributions). Simpler QT models, constrained by stricter assump- tions, are often inaccurate. More advanced models relax these assumptions and improve accuracy, but become significantly harder to solve. Addition- ally, QT models typically provide only aggregate predictions, such as average packet delay, rather than detailed, per-packet insights. This makes them bet- ter suited for general approximations of network performance, rather than thoroughly examining specific, complex scenarios. This has inspired other types of analytical models, intending to improve accuracy, cost, and expressiveness compared to their QT counterparts. On the one hand, fluid queuing models iterate over traditional discrete QT mod- els while assuming that transmitted data can be represented as a continuous value. While this assumption does not hold in reality, it allows for network performance models built through systems of differential equations, which can be solved efficiently. Hence, these models are inexpensive, while the in- clusion of the temporal component in the differential equations also makes them more expressive. Alternatively, other researchers turn to Network Calculus (NC) [7, 8]. Unlike QT, initial NC models aimed to reduce the number of assumptions, include the temporal component, and provide predictable and theoretically proven correct performance predictions at a low computational cost. This is achieved by offering worst-case bounds for the packet delay as a function of time. However, while the bounds are proved to be correct, early NC models also show that these tend to be too pessimistic, while more complex NC models prove to be too computationally expensive to be practical. By contrast, an old yet popular alternative for building network mod- 11 Discrete Event Simulation (1988) Early Parallelizable DES (2001) New Parallelizable DES (2016) Queuing Theory (1963) Network Calculus (1991) Machine Learning Models (2001) ML + Analytical Hybrid Models (2019) Fluid Queuing Models (1999) DL-Accelerated DES (2021) Deep Learning Models (2018) Simulation Analytical Models Maching Learning Models Hybrid Approaches Other Analytical Models Model-tuned Emulation (2018) Accelerated DES (2004) Simulation with DL- Enhanced Accuracy (2023) Figure 2: Taxonomy of network performance models. Solid line arrows indicate direct evolution, while dashed line arrows indicate inspiration or a âresponse to". Year indicates the year of the earliest publication within that category. els is simulation, specifically Discrete Event Simulation (DES). It allows for accurate, fine-grained results. Popular DES projects like OMNET [36] and ns [28] are open source, allowing researchers to share the implementations for newer protocols and devices and facilitating their use. The most significant limitation of DES is its computational cost, which is compounded by the fact that its sequential nature makes it extremely hard to parallelize. As a result, the development of parallelizable DES (PDES) became a prominent research area, driven both by the technical challenges involved and the po- tential benefits: an accurate, detailed modeling approach that could scale to large networks if implemented effectively. QT and other analytical models also influenced the introduction of the first ML models. Originally, the researchers referred to the former as âformula- based" and the latter as âhistory-based" [37]. The objective was for these models to offer better accuracy-cost trade-offs compared to the analytical models. However, ML models would not start to thrive until 2018, with the introduction of DL. Newer architectures, such as Graph Neural Networks [24], were expressive enough to extract and process as much information as was available and produce more accurate results. Since their introduction, DL models have dominated, completely overtaking analytical models as they offered more accurate performance predictions at similar or lower computa- 12 tional costs. Furthermore, beyond building ML or DL models directly, there is also an interest in integrating them into previously researched approaches. We refer to these as hybrid approaches and are, by their nature, extremely varied as to how they may achieve this. For example, ML and analytical models can be combined by using the output predictions of one approach as input to the other and obtain an overall more accurate prediction than if done separately [38, 39]. Another approach is to augment network emula- tors, useful for network verification but not for performance prediction, with queuing models and Bayesian optimization to enable accurate performance prediction [40, 41]. One of the most promising directions involves enhancing DES by integrating fluid models and, more recently, DL. This approach aims to support parallelization and lower simulation costs by replacing selected components with alternative models, while preserving the high accuracy and expressiveness of traditional DES [42, 15]. Finally, recent work has explored using DL models to enhance simulation accuracy in situations where they are unable to predict network behavior faithfully [43, 44]. 3. Network Simulation This section focuses on network models that are implemented through simulation. These are summarized in Table 2. 3.1. Discrete Event Simulation Discrete Event Simulation describes the scenario through a global state and a sequence of âdiscrete events" over time [45]. These events are defined as points in time at which the state of the simulation (i.e., the network and the traffic within it) changes. It includes the generation of packets being introduced into a link, reaching the other side and being buffered, to then being queued and processed by the device. The simulator models the state of the network devices and the rules to process the different events by study- ing, and sometimes even re-implementing their protocols. Protocols can be studied through their specification (e.g., RFC publications). 13 Model Type Input scope Output scope Traffic type Performance metrics Evaluation REAL [46] DES Full network scenarios Packet-level Any Full packet path informa-tion ns [28], -2,-3 [29] DES Full network scenarios Packet-level Any Full packet path informa-tion OMNeT,OM-NeT++ [36] DES Full network scenarios Packet-level Any Full packet path informa-tion OPNET [47] DES Full network scenarios Packet-level Any Full packet path informa-tion CaSiNo [45] DES Full network scenarios Packet-level Any Full packet path informa-tion WNS [48] DES Full network scenarios Packet-level Any Full packet path informa-tion IKRSimulationLibrary [49] DES Full network scenarios Packet-level Any Full packet path informa-tion Javamodelingtools [50] DES Full network scenarios Packet-level Any Full packet path informa-tion gem5 [51] DES Full network scenarios Packet-level Any Full packet path informa-tion 14 pd-gem5 [52] DES Full network scenarios Packet-level Any Full packet path informa-tion Testbed data SimBricks [53] Modular DES Full network scenarios Packet-level Any Full packet path informa-tion Simulated data SplitSim [54] Modular DES Full network scenarios Packet-level Any Full packet path informa-tion Simulated data DONS [18] DES Full network scenarios Packet-level Any Full packet path informa-tion Simulated data Unison [55] DES Full network scenarios Packet-level Any Full packet path informa-tion Simulated data NSX [56] DES Full network scenarios Packet-level Any Full packet path informa-tion Only evaluates cost, not accuracy Parsimon [57] Link-level DES Full network scenarios Flow-level TCP (Focuses on DCTCP, but generalizable) Tail FCT (90thpercentile orhigher) Simulated data Table 2: Summary of simulated network performance models 15 The earliest dedicated network DES simulator is REAL [46], originally built to evaluate the performance of queuing algorithms in gateways. It then acted as a basis for the more general purpose âThe Network Simulator" or ns [28]. ns has been updated over the years, reaching v2.0 (known as ns- 2) in 1997, and later v3 (ns-3) in 2010 [29]. Along with OMNeT (later to become OMNeT++) [36], they are the most widely used network simulators in academia since their creation in the late 1990s. Note that, during their development, many alternative DES software were released. This includes OPNET [47], CaSiNo [45], Open WNS [48], IKR Sim- ulation Library [49], Java modeling tools [50] and gem5 [51]. Ultimately, ns and OMNeT remained the most popular choices due to two factors. First, they are open-source projects with continuous development over the years, allowing them to stay updated and support new technologies. Second, both have permissive licenses that allow them to be used freely for research pur- poses: ns uses the GNU GPL, and OMNeT uses the Academic Public license. The main advantage of DES is its completeness: by fully simulating the individual interactions in the network, the simulator can return accurate and complete descriptions of the traffic behavior. It can also be used to understand cross-traffic interactions, the impact of the network topology and routing, and congestion control protocols. Because of its accuracy and level of detail, DES is the preferred choice of network operators whenever applicable. Furthermore, as we explore other alternatives of network models, one quickly realizes how DES is widely used as a baseline (discussed later in Section 7.5). In addition, in the case of models that undergo some âtraining" process, DES is commonly used as a source of the training scenarios due to its ability to generate large quantities of scenarios, specifically those too hard to capture in real-life networks. However, its completeness also results in its main drawback: computa- tional cost. The cost of DES is proportional to the number of events in the network and, in turn, to the amount of traffic in the network, which becomes unmanageable in larger, high-capacity networks [58, 15, 16]. Furthermore, this is exacerbated by the fact that DES simulators, due to the sequential nature of the events, are usually implemented as single-thread programs (we cover PDES and its challenges in the next subsection). Furthermore, sometimes simulation software fails to accurately describe certain protocols or network devices. This may be because the implementa- tion of certain devices is unknown, protected by intellectual protection laws, so their behavior cannot be accurately replicated by simulators [58, 40]. Sim- 16 ilarly, as we discuss later in Section 7, the evolution of internet traffic and algorithms used may result in different implementations of protocols such as TCP, and the release of new versions that may yet to be supported by the simulation software [59, 60]. These factors result in gaps in the sim- ulation software, even becoming outdated if not continuously maintained. Conversely, to aid future updates, the simulators end up with a modular architecture, allowing new components to interact with existing ones, ex- panding the simulatorâs applicability over time. 3.2. Parallel Discrete Event Simulation Because of the high computational cost, there has always been an incen- tive to develop Parallel Discrete Event Simulation (PDES) [61, 62]. This consists of dividing and processing the sequence of events in parallel while maintaining the global state between events. While this does not reduce the computational effort (if anything, the required synchronization mechanisms will require an additional effort), it does reduce simulation time by splitting the load between multiple processes. Most PDES work by splitting the simulation into Logical Processes (LPs). That is, the simulation itself is split across these LPs, a process done man- ually, where each one runs as if it were its own simulation. Ideally, the LPs are selected to balance the number of events while minimizing inter-process communication, which is much slower than events handled fully locally. To maintain the global order of events, a synchronization algorithm is required. While many approaches exist, these can be categorized as either conserva- tive or optimistic [63]. Conservative synchronization algorithms attempt to minimize causality errors, i.e., when the LPs process events out of order, ne- cessitating a rollback. Optimistic synchronization algorithms, in contrast, try to maximize the degree of parallelization at a higher risk. Ultimately, many PDES simulators offer both options, as performance may vary depending on the scenario. While the benefits of PDES are evident, its complexities have prevented it from completely replacing DES. The inter-process messaging and synchro- nization costs introduce significant overhead while reducing the effective par- allelization. Correctly defining the LPs is cumbersome, making their effective use more difficult [18]. Furthermore, most common networks are hard to par- tition to begin with âeven if the topology is easily partitioned (e.g., a fat tree topology split into its branches), there will still be large volumes of traffic that cross these boundaries. Overall, networks have proven hard to 17 parallelize, with the gains obtained from parallelization outweighed by the overheads present in PDES. Still, many simulators, including ns-3 and OM- NeT++, have added support for PDES. There have also been developments of PDES inspired by existing DES, like pd-gem5 [52] based on gem5 [51]. Recently, novel approaches have been developed to further reduce PDEsâ overhead. SimBricks [53] introduces the concept of modular simulation: basi- cally, it integrates other simulators to model different aspects of the network, such as OMNeT++ and ns-3 of the network itself and gem5 for the hosts, for example. This both exploits the features awarded by each integrated sim- ulation software and increases speed by running each simulator in parallel. However, the authors themselves identify that their simulator cannot acceler- ate individual components. This leads to the simulation being bottlenecked by the slowest components [54]. Furthermore, requiring interoperability be- tween simulators results in some of their features being lost (e.g., gem5âs atomic memory protocol) and limits the scenarios SimBricks can cover, such as only simulating single-core hosts. Some of these issues are addressed in its expansion, SplitSim [54]. Extra features include support for mixed fidelity simulation, reducing the accuracy of certain components to lower costs; decomposition of the slowest compo- nents; and an improved synchronization algorithm. It also simplifies the user configuration through an orchestration framework. Another novel solution is the implementation of DONS [18]. Unlike other simulators, DONS follows a Data-Oriented design in its implementation, re- structuring how memory is organized and accessed to improve paralleliza- tion. However, these benefits only apply to thread-based parallelization in multi-core processors, but not to multiple processes across different machines. Hence, to facilitate distributed execution, it utilizes an automatic LP par- titioning algorithm. DONS prioritizes correctness, both by mathematically proving the robustness of its Data-Oriented design and by employing a con- servative synchronization algorithm. However, DONSâs biggest limitation is its Data-Oriented design, making it incompatible with other PDES imple- mentations. This requires all the simulation logic to be re-implemented to fit the new paradigm [55]. Conversely, Unison [55] follows a more standard approach. Its novelty arises from its automatic fine-grained LP partition, easing configuration and improving the efficacy of the selected LPs, and from dynamic scheduling to avoid bottlenecks. It can also reuse frameworks meant for other DES simu- lators like ns-3. While effective, it also comes with important limitations: its 18 automatic LP partition does not support stateful links (e.g., wireless chan- nels), and its load balancing assumes that all the processors it runs on are identical. A similar, recent approach is that of NSX [56]. Unlike other PDES, NSX is meant to run in Graphical Processing Units (GPUs). The primary motivation behind this choice is to capitalize on the current popularity of GPU-heavy data centers designed for LLMs. NSX is designed for GPUsâ ex- treme levels of parallelization: for example, using local event queues to main- tain a âlocal" event order. The main drawback of this approach is presuming the availability of plentiful, powerful GPU hardware, which is monetarily expensive. An alternative approach to accelerate DES to those presented earlier is Parsimon [57]. Parsimon decreases computational cost while enabling effi- cient parallelization by decomposing a network topology into its links. That is, for each link in a flowâs path, Parsimon studies its experienced delay through a set of independent simulations. Each link simulation predicts link behavior by approximating the expected experienced load in the original topology but in a smaller scenario. These link-level simulations are designed to light, and, as they are independent, they can be executed in parallel. Par- simon also offers the option of using a greedy clustering algorithm to share simulation results between similar links, thus reducing the number of them to be executed, albeit at the cost of accuracy. However, the link simula- tions introduce error (usually overestimating delays) and are incompatible with packet-level visibility. Instead, Parsimon can only predict performance metrics that can be computed as the aggregation of the performance at each link, such as the FCT. Because it tends to overestimate, Parsimon is better suited for tail-prediction âi.e., upper bound approximations. Overall, building an efficient PDES is non-trivial. Due to the sequential nature of the DES, the authors ultimately need to make some concessions to maximize the efficiency of the simulationâs parallelization. Yet, when successfully applied, PDES achieves accurate and complete results with low inference times, assuming the users have the hardware to run it on. 3.3. Summary Overall, simulation, and in particular DES, have been the most complete network model available. It remains the most accurate option, and con- tinuous support both by the research community and industry allows DES simulators such as OMNeT++ [36] and ns-3 [29] to keep up with the advances in modern networks. Its biggest threat, however, is the computational cost. 19 Traditional, single-threaded DES cannot simulate large networks or modern data centers, and even if it can, it is at a prohibitively high computational cost. While interest in PDES existed ever since the inception of DES itself, its technical challenges were not addressed properly until fairly recently, with examples like SplitSim [54], DONS [18] and Unison [55]. Even then, it is important to note that PDES (except for Parsimon [57]) does not reduce the computational cost of simulation (if anything, it will increase it due to the synchronization overhead), but rather offloads it to mutiple machines. Hence, without the hardware available to run them, simulating large network scenarios are still out of reach. 4. Analytical Models This section focuses on analytical network models, summarized in Ta- ble 3. These are generally based on some formal theory and are implemented through systems of equations. 4.1. Queuing Theory Queuing Theory (QT) is a field of mathematics that studies the behavior of queue-like systems. In them, a system will receive requests and service them according to a specified distribution (e.g., Poisson). If the system is occupied, requests will be queued until they can be processed. The original model was proposed in the 1960s in [6], and was later refined for computer networks in [64]. With them, devices and protocols can be approximated through these models to extract relevant performance metrics such as the mean queuing delay. Queuesâ definitions vary in complexity [45]. Simpler queuing models can be solved instantly, but are limited to simple behaviors and therefore have more stringent assumptions. For example, the simplest queue is the M/M/1 queue, which assumes (1) a Poisson arrival process of packets, (2) exponen- tially distributed service times, and (3) a single First-In, First-Out (FIFO) queue with infinite buffer. These properties make calculating factors like av- erage package queuing delay or service time trivial, but are also unrealistic. While the infinite buffer is the clearest example, an important assumption is that of a Poisson arrival process. In practice, internet traffic distributions have been shown to be self-correlated and fit best heavy-tail distributions like Weibull [4] and log-normal [5] distributions. 20 Model Type Input scope Output scope Traffic type Performance metrics Evaluation [64] M/M/1, M/G/ â , M/G/1 queues Single-flow scenarios Flow-level Non-specific Average packet de- lay, buffer overflowprobability Analytical evaluation [65] M/G/ â queue Traffic- matrix scenarios Flow-level Non-specific Loss rate Simulated data evaluation [66] GI/G/1 queue Single-flow scenarios Flow-level Non-specific Upper and lower bounds, averagepacket delay Simulated data evaluation [67] System of M/M/ â queues Traffic- matrix scenarios Flow-level TCP (Tahoe) Average packet [loss probability, RTT] Simulated data evaluation [68] System of M/G/ â queues Traffic- matrix scenarios Flow-level TCP (Tahoe) Average packet [loss probability, RTT] Simulated data evaluation [69] Modified M/M/1 queues Traffic- matrix scenarios Flow-level Non-specific Flow throughput, average packet delay Simulated data evaluation [70] ODE fluid queuing model Single-flow scenarios Flow-level (temporal) TCP (Reno and Vegas) Flow throughput No baseline 1 AIMD [71] ODE fluid queuing model Traffic- matrix scenarios Flow-level (temporal) TCP (Generic) Flow throughput and mean RTT persesion Simulated data evaluation [72] ODE fluid queuing model Traffic- matrix scenarios Flow-level (temporal) TCP (Generic) Average RRT and loss rate Simulated data evaluation 1 Analytical comparison between TCP versions, no comparison with baseline. 21 [73] SDE fluid queuing model Full network scenarios Flow-level (temporal) TCP (Generic w/ RED) Flow throughput,average RTT (butevaluation only evaluates queue-length) Simulated data evaluation [74] SDE fluid queuing model Full network scenarios Flow-level (temporal) TCP (Sack, Reno, and NewReno) Flow throughput,average RTT (butevaluation only evaluates queue-length and windowsize) Simulated data evaluation multi-AIMD[75] Fluid/ discretehybrid queuingmodel Full network scenarios Flow-level (temporal) TCP and UDP Flow throughput, average RTT Simulated data evaluation [76], [77] Fluid/ discrete hybrid queuingmodel Full network scenarios Flow-level (temporal) TCP and UDP Average flow throughput and RTT (only droprate and windowsize retain a tempo-ral component) Simulated data evaluation [78] PDE fluid queuing model Traffic- matrix scenarios Flow-level (temporal) TCP (Generic) Average flow throughput, FCTand loss rate Simulated data evaluation [79] PDE fluid queuing model Traffic- matrix scenarios Flow-level (temporal) TCP (Scalable TCP) Flow throughput Simulated data evaluation [80] ODE fluid queuing model Full network scenarios Flow-level (temporal) UDP 2 and TCP (Reno) Flow RTT, throughput and loss rate Simulated data evaluation 2 UDP only as supported as background traffic. 22 [81] Discrete and fluid queuingmodel Traffic- matrix scenarios Flow-level (temporal) TCP Flow packet delay (evaluation focusesin average queuelengths) Simulated data evaluation TFA [7, 8] ADNC Full network scenarios Flow-level (temporal) Non-specific Worst-bound packet delay Analytical evaluation D-BIND [82] ADNC Full network scenarios Flow-level (temporal) Non-specific Worst-bound packet delay Real data evaluation [83] ADNC Full network scenarios Flow-level (temporal) UDP and traffic with throughput guarantees Worst-boundpacket delay Analytical evaluation SFA [30] ADNC Full network scenarios Flow-level (temporal) Non-specific Worst-bound packet delay Analytical evaluation PMOO[31] ADNC Full network scenarios Flow-level (temporal) Non-specific Worst-bound packet delay Simulated data evaluation [84] ADNC Full network scenarios Flow-level (temporal) Non-specific Worst-bound packet delay Analytical evaluation TMA [35] ADNC Full network scenarios Flow-level (temporal) Non-specific Worst-bound packet delay Simulated data evaluation [85], ODNC Full network scenarios Flow-level (temporal) Non-specific Worst-bound packet delay Analytical and Simulated data evaluation [86] ODNC Full network scenarios Flow-level (temporal) Non-specific Worst-bound packet delay Simulated data evaluation 23 [87] ODNC Full network scenarios Flow-level (temporal) Non-specific Worst-bound packet delay Simulated data evaluation [88] SNC Traffic- matrix scenarios Flow-level (temporal) Non-specific Stochastic worst- bound packet delay Analytical evaluation [89] SNC Traffic- matrix scenarios Flow-level (temporal) Non-specific Stochastic worst- bound packet delay Analytical evaluation [90] SNC Traffic- matrix scenarios Flow-level (temporal) Non-specific Stochastic worst- bound packet delay Analytical evaluation [91] Analytical model fromRFCdefinitions Single-flow scenarios Flow-level (temporal) TCP (generic with phase effects and RED) Flow throughput Simulated data evaluation [92] Stochastic analyticalmodel fromobservations Single-flow scenarios Flow-level (temporal) TCP (Reno) Flow packet rate and throughput Real data evaluation [93] Utility maximizationmodel Traffic- matrix scenarios Flow-level TCP Flow throughput Analytical evaluation [94] Utility maximizationmodel Traffic- matrix scenarios Flow-level TCP Flow throughput Analytical evaluation Table 3: Summary of analytical network performance models 24 Alternatively, relaxing these assumptions will result in more complex models, like the G/G/1 queue, which assumes general distributions for both packet interarrival and service times, or the modified M/G/â queue in [65] for modeling video traffic. By not being bound by such assumptions, the resulting model is harder to solve, and may not even have an exact solu- tion [95]. Usually, approximate solutions are extracted from solvers such as Buzenâs convolution algorithm [96], mean value analysis [97], Local Balance Algorithm for Normalizing Constants and Coalesce Computation of Normal- izing Constants [98]. A recent proposal is that of [66], where the authors use nonstandard analysis for analyzing GI/G/1 queues. Hence, it is also common to build more complete models using an ensem- ble of simpler queue models. An example can be found in [67, 68], where a model of TCP Tahoe was built out of a graph made out of M/M/â queues (and later M/G/â, assuming a generalized service time distribution), each representing a state of the protocol and which the packets traversed. Their model also covers link interfaces through an M/M/1/B queue, but only con- siders line topologies in their evaluation. Another example can be found in [69], where the authors propose a model capturing bursty and phase-type traffic in a multistage switch network. It explains how these traffic profiles are aggregated and uses adapted M/M/1 queues to approximate the more complex arrival distributions. QT models are further limited by only working through distributions. First, it only allows models to predict aggregate (e.g., average) performance measures, such as the average packet delay. Second, no matter how expres- sive the distribution is, it will always be less descriptive than working with individual traffic packets, as is done in DES. Next, they tend to model only traffic flows, independently of the underlying network hardware. The latter is abstracted into âservers" that delay packets by a given amount, according to a constant or exponential distribution, depending on the queue model. We also note that early queuing models focused on highly specific sce- narios, typically modeling single flows without accounting for cross-traffic from other TCP connections or background traffic. That being said, this limitation has been addressed in the SotA [67, 68, 69], incrementally making them viable in a wider range of scenarios. That being said, queuing models for TCP implementations are susceptible to becoming outdated as networks evolve and the TCP flavor they support becomes deprecated. In spite of this, QT models remain a useful tool for network operators to quickly obtain a general and approximate description of the expected behavior. 25 4.2. Fluid Models Fluid models (a.k.a. liquid models) are a subtype of QT models. Un- like standard (discrete) QT models, which account for data transmission in indivisible packets, fluid models treat data as a continuous, infinitely divis- ible flow. This allows for more expressive models to be developed based on systems of Ordinary, Stochastic, and, later on, Partial Differential Equations (ODE, SDE, and PDE, respectively). Since plenty of ODE and PDE solvers exist, due to their prevalence in other fields, fluid models tend to be computationally inexpensive to solve. Furthermore, they are more expressive, as their description by sets of differ- ential questions also allows authors to include a temporal component in their metrics predictions, unlike discrete models that focus on aggregated (e.g., average) results. Being able to formulate the network state through a series of equations, akin to other fields like thermodynamics and electrical systems, is also appealing. However, ODEs also introduce important limitations. By themselves, these systems introduce a degree of error through approximation âsolvers based on numerical solutions, for example, will inevitably introduce a degree of error due to their approximate approach. These inaccuracies are much more prevalent in computer networks due to their discrete nature: digital information is measured in bits and sent through indivisible packets; decisions taken by transport protocol algorithms, like TCP, are made at a resolution of these individual packets. Hence, any formulation that deals with the network as a continuous system will be limited due to this fundamental difference. Nonetheless, its advantages prevailed, and fluid models proliferated in the SotA between 2000 and 2010. For example, in [70], the authors implemented a fluid model of both TCP Reno and TCP Vegas to compare the two. The comparison, however, is limited to the flow control section of both flavors. In AIMD [71], the authors propose a generic TCP model, including a steady- state solution to extract the flowâs throughput and mean stationary inter- congestion time. However, like other generic TCP models, it does not cover advances and differences between TCP implementations. In [72], the authors propose a generic TCP model to predict performance metrics relevant to video transmission (packet RTTs and loss rates). The model assumes that packet loss can be described as a Poisson Process. Next, in [73], the authors define a system of SDE, later converted to a system of ODE, to model Random Early Detection (RED), a mechanism of Active Queue Management (AQM). The model can be expanded from 26 modeling a single router to a network with multiple TCP flows, and scales to larger instances through flow aggregation. However, the traffic matrix it uses ignores the order of visited routers and assumes a generic version of TCP. Shortcomings of this model are later addressed in [74]: it expands the RED model to include other types of AQM policies, specific versions of TCP (SACK, Reno, and NewReno), and expands the routing information from the network topology considered by it. The model also introduces pruning of irrelevant elements (e.g., non-congested queues) to reduce the number of variables and improve computational performance. There are also examples of models that attempt to combine both dis- crete and fluid queuing models. In multi-AIMD [75], the authors expand the AIMD model to support the presence of both TCP and UDP flows. It considers a fluid model that feeds into an M/M/1/B (discrete) queue model for the network devices according to the network topology. In [76, 77], the authors follow a different approach, where flows are described through a dis- crete state (i.e., empty queues, non-congested flow, and congested flow), each with its own system of SDE. It allows modeling a more complex set of be- haviors than a single SDE. The model supports different TCP flavors and UDP, albeit the latter following a specific On/Off interarrival traffic distri- bution. Importantly, the evaluation only covers predictions of the average flowâs throughput and RTTs over the scenario, and the papers do not specify how to compute the time-aware values. One of the first examples of a model that uses a system of PDEs can be found in [78]. The model exploits the increased expressiveness of fluid models when expressing flow behavior over time, to better deal with âmice" flows. These are short flows whose completion time is more dependent on propagation delays than transmission delays. The model considers a generic TCP version. It still relies on assumptions (e.g., mice flow lengths are expo- nentially distributed) and does not address the underlying topology. In the evaluation, despite including the temporal component in its reasoning, they only consider average values for the throughput and FCT. Later, in [79], the authors define a model using PDEs to model Scalable TCP. While this model supports multiple flows, it assumes constant RTT and continues to disregard the network topology. Later on, we have models that cover more complex network scenarios. For example, in [80] the authors develop an ODE model for considering queuing policies other than FIFO. This includes fair queuing, longest queue first, and shortest queue first. The model also supports multiple TCP flows and back- 27 ground UDP traffic. The model can predict the TCP flowâs throughput and buffer occupancy, and the UDPâs loss rate. However, the model is adjusted for TCP Reno, specifically during the congestion avoidance phase. Another example is in [81], where the authors modify both discrete and fluid queuing models to capture transient states of TCP flows. While the obtained fluid model is less accurate, its lower computational cost allows it to be applicable on larger networks, unlike the discrete model. 4.3. Network Calculus Network Calculus (NC) is a set of techniques used to study network per- formance introduced in [7, 8]. Unlike QT, which describes network traffic through traffic distributions, NC describes traffic through arrival and service curves. These are then used to generate worst-case bounds for the flowâs per- formance metrics over time. In [7], the authors defined network elements, like delay lines, buffers, and regulators. Then, in [8], the authors show how these elements can be combined to define a network model. Briefly, NC became popular as a middle point between QT and DES, offering inexpensive predic- tions, relying on fewer traffic assumptions, and with an integrated temporal component NC models, however, are not flawless. While NC ensured a correct worst- case bound, originally these were too permissive for the prediction to be useful. Conversely, tighter bounds may result in increased model complexity and computational cost. Due to this, SoTA NC models attempt to push the Pareto front by pursuing a better balance between tight bounds and the cost of obtaining them [35]. Ultimately, NC models can be subdivided into three categories: Algebraic-based Discrete Network Calculus (ADNC), Optimization-based Discrete Network Calculus (ODNC), and Stochastic Net- work Calculus (SNC). Finally, a significant limitation shared across all NC models is that it can only work in feedforward networks âi.e., where routing paths do not result in cycles. This aspect was studied in [99], where the authors tried to define a delay bound for generalized topologies, but only found it possible when link utilization is extremely low. Otherwise, the packet delay for a given flow may be influenced by flows that do not share a queue within their routing paths or have been completed before the given flow has even started. As the authors state, a delay bound may not even exist beyond a large enough link utilization. This can be addressed by turning general network topologies into functionally feedforward ones. For example, networks can be shaped into 28 spanning trees by removing links from consideration. Alternatively, in [100] they propose modifying the flowâs routing paths through turn-prohibition. While the latter is less drastic, both decrease flow throughput. Empirical evaluation suggests that this effect worsens in larger topologies. 4.3.1. Algebraic-based Discrete Network Calculus (ADNC) It is the approach followed by the original proposal [7, 8], where network elements are defined and can be chained. The delay bounds are solved alge- braically through the use of (min, +) and (max, +) algebra [30]. Later on, the original proposal was referred to as Total Flow Analysis (TFA). One of the first improvements was using piece-wise functions to replace the linear arrival and service curves, as used in [82], resulting in more expressive and tighter definitions. [83] also extends the original proposal by supporting flows with flow control âi.e., flows that reserve network resources for performance guarantees. Later in [30], the authors proved that TFAâs delay bound overes- timates the impact of flow bursts at each node in a flowâs path. This can be addressed by defining and exploiting the concatenation property (known as the Pay Bursts Only Once Principle or PBOO), resulting in Separate Flow Analysis (SFA). The PBOO principle was extended in [31] to make it applicable to apply NC for multiplexing flows in the same node, renamed as Pay Multiplexing Only Once (PMOO). In theory, PMOO also allowed for considering arbitrary multiplexing of flows, unlike previous approaches, which assumed FIFO mul- tiplexing. However in [85] shows that arbitrary multiplexing may result in looser bounds than those obtained with SFA. Next, the authors at [84] pro- pose extending the PMOO model using bounded arrival curves, making the model more efficient with the aim of unlocking the use of more accurate yet complex function definitions for the arrival and service curves. Finally, in [35] the authors compare both ADNC and ODNC alternatives in the SotA, and offer an improved version of ADNC, named Tandem Matching Analysis (TMA). It considers all possible (min, +) operations during the network de- composition to obtain the least pessimistic delay bound. While this approach results in an exponential number of decompositions according to the network size, it is optimized to keep computational costs akin to similar alternatives, as proved by their evaluation. 29 4.3.2. Optimization-based Discrete Network Calculus (ODNC) These models find the delay bound for a given flow in the network by solving a Linear Programming Problem (LPP). The LPP is formulated to identify the worst possible delay according to a set of temporal, spatial, and service constraints. An early example is introduced at [85] as an alternative the PMOO model. While more accurate, especially when facing complex scenarios like non-FIFO flow multiplexing, this approach suffers from an extremely high computational cost. This is because solving the delay bound for a given flow is an NP-hard problem, as both the number of LPPs to solve and constraints in each of them increase exponentially with the network size [86]. Hence, authors have looked at heuristics or scenarios where the compu- tational cost is more bounded. In the same paper [86], the authors find that when considering tandem networks âgraphs that can be described as a directed path with no shortcutsâ the computational cost decreases from exponential to polynomial. They also prove a heuristic where a universal service curve can be found for all flows in the network, further reducing the computational cost. Another heuristic is proposed in [87] where a combina- tion of Monte-Carlo and Direct Search was used to reduce the cost of solving the LPP. However, an analysis done by [35] shows that these heuristics are insufficient to make solving the problems feasible for large networks. 4.3.3. Stochastic Network Calculus (SNC) While traditional (deterministic) NC offers a strict delay bound, SNC instead defines delay bounds that can be incorrect with a small probability of error [101]. The earliest paper proposing this approach can be found in [88], where they use bounds for the moment generating functions of random variables. While there have been several attempts to define a complete SNC [13], the authors at [89] are the first to aggregate formulations from previous research to build one that satisfied a set of listed properties (e.g., service guarantees, per-flow service). However, later work by [102] showed that such a model is not purely stochastic and struggles in aspects such as capturing statistical flow multiplexing. In [90], the author proposes expanding existing SNC by estimating the effective network bandwidth to obtain better delay bounds. Ultimately, the biggest drawback of SNC is its relatively recent development, making it less explored and developed than its deterministic counterparts. 30 4.4. Other Analytical Models Analytical models that are not based on either QT or NC are generally rare, as this implies losing the accumulated knowledge from previous research. Nonetheless, sometimes models may be built based on other principles, or the authors wish to avoid the weaknesses present in these fields. A common source of alternative analytical models is building ones based on the empirical observations, or, in the case of well-defined protocols like TCP, on the RFC definitions. In [91], the authors implement an analytical model for TCP with forward acknowledgments using Rate-Halving. This model was later evaluated considering phase effects and RED. However, the evaluated topologies were small, generally single-link topologies, and the Internetâs topology was simplified to a single link with losses between the routers. Next, in [92], the authors build a stochastic model for TCP Reno. It processes flows into rounds according to the congestion window. Unfortu- nately, it relies on several assumptions for the model to be solved through a closed-form solution: losses are independent of those in different rounds, and RTT is assumed to be independent of the window size. The model also does not cover Renoâs fast-recovery algorithm or the small differences across implementations. Alternatively, there has been research applying game theory to model congestion control algorithms. This idea was introduced in [93], where the congestion algorithm was tasked to find a Nash equilibrium where perfor- mance across all present flows is maximized. The authors propose using the Nash arbitration scheme to predict the throughput allocation for each flow while proving the existence of an optimal allocation. Inspired by it, in [94] proposes two models. The first, an ideal model, relies on knowing the âutility" obtained by each flow at a given throughput, which is unknown beforehand. The second model simplifies the first, being decomposed into a solvable dual problem. A strength of this approach is that models considered link capac- ities in their reasoning, which was rare for analytical models at the time. Conversely, this approach had two main drawbacks. First, in practice, con- gestion algorithms like TCP may not necessarily allocate throughput solely by maximizing bandwidth allocation. Second, the proposed models are gen- erally too complex to be applied to real networks, while their simplified forms introduce inaccuracies. 31 4.5. Summary In summary, analytical models aim to be a cost-effective alternative to DES. The first models are based on Queueing Theory, which uses queues or systems of queues to describe both network devices and protocols [6, 64]. However, simpler queue models lack accuracy due to oversimplistic assump- tions, while more complex models are no longer cost-effective to solve. Fluid models are also based on QT, but allow flow payloads to be infinitely divis- ible. While this contradicts how traffic packets behave in reality, it allows models to be formulated through a system of differential equations, reinforc- ing their cost-effectiveness while incorporating the temporal component in their prediction [70]. In response to QTâs limitations, Network Calculus was developed as an alternative for network modeling [7, 8]. Unlike queuing models, NC models included the temporal component and predicted performance bounds rather than direct estimations. However, like QT models, NC models are also split between inaccurate predictions (i.e., loose bounds) or prohibitively computa- tional costs. Finally, while there are analytical models that do not fall under any of these fields, their use tends to be more sporadic and more specialized (e.g., using Game Theory to understand bandwidth allocation in congestion- controlled traffic [93, 94]). 5. Machine Learning Models This section focuses on network models that predict network performance behavior through the use of ML models. Discussed models are summarized in Table 4. 5.1. âShallow" ML Models The earliest attempt to use ML to predict network performance that we identified was in [37]. In it, the authors considered both âformula-based" (an- alytical) and âhistory-based" (temporal regression) models when predicting TCP throughput. They proved analytical modelsâ limitations when dealing with saturated traffic, while even simple regression models like moving aver- age (MA) or exponentially weighted MA (EWMA), worked fairly well. Still, the purposes of these models were not to build a tool, but to evaluate the feasibility of ML models. 32 Model Type Input scope Output scope Traffic type Performance metrics Evaluation [37] MA, EWMA, Holt-Winters Single-flow scenarios Flow-level (temporal) TCP (generic) Flow throughput Testbed data PathPerf[103] SVR Single-flow scenarios Flow-level (temporal) TCP (generic) Flow throughput Tesbed data and real data WISE [104] Causal graph Single-flow scenarios Flow-level HTTP connections Network responsetime Real data [105] EVT Multi-flow scenarios Flow-level UDP 50th, 75th, 90th, 99th, 99.9th, 99.99th, 99.999thand 100th per-centiles for packetdelay and jitter Testbed data CLAAP [106] RBFNN Single-flow scenarios Flow-level (temporal) UDP Flow latency Real data [107] DNN Multi-flow scenarios Flow-level UDP Average packet de- lay Simulated data [108] DNN, RF Multi-flow scenarios Flow-level UDP and TCP Average packet de- lay Simulated data RouteNet[109, 110,111] Custom-designedMPNN Full network scenarios Flow-level UDP Average packet de- lay and jitter Simulated data [112] Custom- designedMPNN Full network scenarios Flow-level UDP Average packet de- lay and jitter Simulated data 33 RouteNet-Erlang [113] Custom-designedMPNN Full network scenarios Flow-level UDP Average packet de- lay and jitter, lossrate Simulated data RouteNet-Fermi [17] Custom-designedMPNN Full network scenarios Flow-level UDP Average packet de- lay and jitter, lossrate Simulated data and testbed data RouteNet-Gauss [58] Custom-designedMPNN withtemporalcomponent Full network scenarios Flow-level (temporal) UDP [Average, median, and 90th, 95th, and99th percentile] packet [delay, jitter] Testbed data [114] Custom- designedMPNN withgraphattention Full network scenarios Flow-level UDP Average packet de- lay Simulated data [115] Custom- designedMPNN withgraphattention Full network scenarios Flow-level UDP Average packet de- lay Simulated data [116] Custom- designedMPNN Full network scenarios Flow-level UDP Average packet de- lay Testbed data [117] Custom- designedMPNN Full network scenarios Flow-level UDP Average packet de- lay Testbed data 34 DeepComNet[118] GGNN [23] Full network scenarios Flow-level UDP and TCP TCP flow through- put, UDP averagepacket delay Simulated data [119] GGNN [23] Full network scenarios Flow-level TCP (Reno, Cubic, Bic, Illinois, Veno, Vegas and Ledbat) Flow RTT andthroughput Simulated data [120] GCN [22] Full network scenarios Flow-level UDP and TCP Average packet de- lay Simulated data EAGLE [121] Custom- designedMPNN Full network scenarios Flow-level UDP and TCP Average packet de- lay and loss rate Simulated data xNet [122] Custom- designedMPNN withtemporalcomponent Full network scenarios Flow-level (temporal) UDP and TCP (DTCP) Average packet de-lay, flow throughputand FCT Simulated data GLANCE[123] Custom-designedMPNN Full network scenarios Flow-level UDP Average packet delay and jitter,flow throughput,loss rate Simulated data FlowSeer[124] Ensemble ofGCN [22],DNN withattention andDNN Full network scenarios Flow-level UDP Average packet de- lay Simulated data m4 [125] GraphSage [126] + GRU[127] Full network scenarios Flow-level (temporal) TCP (DCTCP, TIMELY, DCQCN) [Average, 90th per-centile] flow FCTand throughput Simulated data 35 xWeaver[128] CNN Full network scenarios Flow-level UDP Flow FCT and throughput Simulated data and testbed data Deep-Q [129] CVAE [130] + LSTM [25] Multi-flow scenarios Flow-level (temporal) UDP Packet delay and loss rates Testbed data [131] Transformer [132] Single-flow scenarios Packet-level UDP Packet delay Simulated data DeepQueueNet[16] Transformer[132] +BiLSTM Full network scenarios Packet-level UDP Full packet path in- formation Simulated data [133, 134] NP [27] Multi-flow scenarios Flow-level Non-specific Average packet de- lay, flow throughputand loss rates Testbed data Table 4: Summary of ML network performance models 36 Later in PathPerf [103], the authors used a Support Vector Regression (SVR) model to predict TCP throughput. It was trained in a testbed using real network data and diverse routing paths, showing competitive perfor- mance relative to analytical models. SVRs, a popular architecture at the time, are able to learn from limited amounts of data, which is extremely useful considering the cost and difficulties of capturing real-world data for training. However, this architecture still had several limitations: the model could only consider one TCP flow at a time, could only predict average met- rics, and the model had to be retrained for every change to the flowâs path. Another example of an early performance prediction tool is WISE [104]. WISE sits on the edge between performance prediction and network vali- dation: it builds a causal graph from captured traffic traces that focus on HTTP connections and the identified variables, such as the number of packets transmitted, their size, and estimates network bandwidth. A causal graph is a statistical model that defines how variables influence each other in a non- cyclical graph. WISE focused on predicting the HTTP connectionâs response time, both from the network and browsers. The causal graph allows the user to query different values for the specified variables, hence allowing the evalu- ation of âwhat-if" scenarios to understand their impact on the response time. In the evaluation, which consisted of captured data from Googleâs network, it proved to be accurate in predicting both options of the response time. Unlike other ML models, it does not need training. Instead, it learns and builds the causal graph during inference, making the method versatile but slow. Nowadays, âshallow" ML models have fallen out of favor against their DL counterparts, as the latter tend to offer more accurate results due to their more complete architecture. However, âshallow" ML models are sometimes desired due to their efficiency, being able to be trained with few samples and at a low computational cost. A recent example of this is in [105], based on Extreme Value Theory (EVT), a statistical model designed to predict extreme events or worst-case bounds. In this paper, EVT is used to predict upper-bound approximations of metrics like flow latency and jitter. The EVT model is highly efficient: it only required to be trained on 5% of the data available. It was also able to predict scenarios with different topologies and make predictions for the entire network (with multiple-interacting flows) and not only for individual flows. However, the results show that its accuracy for network predictions is significantly lower. Finally, the EVT model also depends on assumptions like stationary flow latencies. Another recent example is that of CLAAP [106]. CLAAP uses a Radial 37 Basis Function Neural Network (RBFNN) to predict flow latency in online gaming sessions. It bases its predictions on previous latency measurements, akin to a regression model such as MA and EWMA in [37]. While the RBFNN is a shallow neural network, it still outperforms other online regression models in its evaluation. Furthermore, it is designed for quick inference speed, as it is a model meant for online management of online gaming sessions. Hence, response time is more critical than creating an accurate yet expensive internal representation of the flow state. 5.2. Deep Learning and Graph Neural Networks The initial attempts to build DL network performance models were tested using Dense Neural Networks (DNNs). In [107], they evaluate the use of DNNs when predicting the average flow delay. While their results show the potential of DL methods by being computationally inexpensive and capable of modeling non-linear relationships, they noted their inability to generalize to unseen topologies and routings. Also, the only traffic profile of packet arrivals considered was an exponential distribution, a simpler distribution than those faced in real-life scenarios. Later in [108], the authors compared building a DNN model against a Random Forest (RF) model using a mixture of UDP and TCP traffic of varying complexity. They ultimately showed that the RF models generally outperformed the DNN models. Hence, researchers quickly moved from using DNNs and looked into alternative, better-suited DL architectures. 5.2.1. RouteNet and Successors Among all the possible alternatives, the family of architectures that pre- dominated were Graph Neural Networks (GNNs) [24]. GNNs are designed to take a graph input and exploit the topological information present. Unlike previous ML and analytical models, which struggled to represent the impact of the network topology and flowâs routing path on their reasoning, GNNs can properly exploit them, leading to their success. This is exemplified by the RouteNet family of models. The original one was described and introduced in [109], and was later more thoroughly examined at [110, 111]. RouteNetâs architecture is based on the Message Passing Neural Network (MPNN) architecture [26]. It works by building a heterogeneous graph that captures the dependencies between links and flows within a network, based on its topology and routing. In principle, using this description allows RouteNet to accurately predict flow 38 delay and jitter in topologies and routing paths unseen during training while maintaining a low computational cost (i.e., milliseconds per network sce- nario). The RouteNet models are trained and evaluated on samples using DES. While effective, RouteNet does have important drawbacks. First, further evaluation has shown limitations in its generalization [135]. This includes larger topologies and link capacities than those seen during training, but also to different traffic profiles, packet sizes, and inter-packet gap (IPG) time distributions. Furthermore, RouteNet can only predict average measures across the entire scenario, and cannot model transitory behavior. Finally, it does not support key network features, such as modeling TCP traffic, Quality of Service (QoS) requirements, or alternative routing paths. To address these limitations and improve overall accuracy, RouteNet has since been extended through successive iterations to cover a broader range of scenarios. The first change was in [112], in which additional features were added to add support for variable queue sizes. The first major expansion, however, came with RouteNet-Erlang [113]. It includes queues in its graph representation of the network alongside links and flows, and its feature extrac- tion is modified to better support inferring over larger topologies than seen during training. It also supports flows parametrized through auto-correlated traffic distributions, based on observations done to internet traffic [4]. Over- all, this allows for a more complete definition of the network and its traffic, better accuracy when dealing with unseen scenarios during training, and introduces support for multiple queues per port, different queuing policies, supporting QoS requirements, and packet loss predictions. The next large iteration is that of RouteNet-Fermi [17]. Rather than predicting the average flow delay directly, RouteNet-Fermi instead learns to predict the mean queue occupancy at each step of the flowâs routing path. This change in the modelâs reasoning results in more accurate predictions and better scaling when facing larger networks, in number of elements, traf- fic intensity, and link capacities. RouteNet-Fermi also expanded the number of supported queuing policies relative to RouteNet-Erlang. Finally, this it- eration of RouteNet was also evaluated with real (testbed) network data, proving its feasibility in more complex traffic scenarios. The most recent iteration of RouteNet is RouteNet-Gauss [58]. It in- troduces a temporal component, splitting traffic scenarios into fixed-time windows, enabling it to model non-stationary traffic and better address the complexities present in real network samples. The window size can be ad- 39 justed to balance model expressivity to computational cost. It also removes the need to specify flow distribution parameters as input, allowing it to accu- rately model non-parametric traffic. Still, RouteNet-Gauss does share some limitations with the original version: specifically, a lack of support for con- gestion control algorithms and generalization to unseen network protocols and traffic distributions from those seen during training. Beyond the main line of RouteNet architectures, there have been improve- ments made by authors other than the original ones. The most common is including an attention mechanism at some point in the message passing phase. In [114], this is introduced to the original RouteNet, while in [115] it is introduced in the RouteNet-Fermi. The inclusion of graph attention mechanisms is used to improve the expressivity of the message passing phase by allowing nodes to weight the relative importance of their neighbors. This mechanism was introduced in the Graph Attention Network [136], which be- came the SotA general-purpose GNN architecture. We also note that, in [115], other improvements were introduced, such as using feature selection to refine the feature extraction process. In [116], the authors also expand RouteNet-Fermi by increasing the fea- tures used to codify flow information. Specifically, they extract the IPG mean, variance, and several percentiles for each flow. They also propose using the packet loss rate as an input for predicting the flow delay, which, while effective, is impractical in real-life scenarios, as either the packet loss rate is not known during inference, or if it is, the average packet delay is al- ready known as well. Finally, in [117], the authors modify RouteNet-Fermi, replacing the use of flow distribution parameters with the raw packet traces and the wavelet decomposition process during flow encoding. This allows for cost-efficient, rich descriptions of non-parametric traffic distributions. The results also suggest the modelâs ability to perform inference on unseen traffic distributions at a minimal penalty to the prediction error. However, this method requires the packet traces of the flows, which are costly to obtain and not always available. 5.2.2. Other GNN Models While RouteNet has inspired many of the GNN models, there are other alternatives present in the SotA. Published around the same time as the original RouteNet paper, the au- thors in [118] also propose a GNN-based network model. Like RouteNet, the authors also proposed building a graph that captures the dependencies 40 between links and flows. Unlike RouteNet, its architecture is based on Gated GNNs (GGNNs) [23] rather than MPNNs. Next, it can model congestion- controlled traffic by representing both the original stream and the ACK mes- sages as separate flows. However, while RouteNetâs hypergraph is a heteroge- neous graph, with the different network elements being processed differently, the hypergraph in [118] is a homogeneous graph, and its nodes are only differentiated through a one-hot feature. Furthermore, its simpler feature extraction results in lower accuracy and generalization to unseen network protocols and traffic intensities. This approach was later expanded in [119]. First, the hypergraph it builds also includes device ports (referred to as interfaces), and path nodes that encode the flowâs routings. The encoding of the network elements is also extended to support multiple TCP versions. Overall, it shows lower error rates than their baseline analytical models, but performance varies depending on the TCP version and the routing path length. Furthermore, the TCP version is encoded through one-hot encoding, meaning that it can only be applied to versions covered during training. Next, in [120], the authors propose using a Graph Convolution Network (GCN) [22] architecture, rather than an MPNN, to predict traffic delays. Un- like previous networks, they apply the graph to the original network topol- ogy instead of building a hypergraph of relationships. Unfortunately, their methodology is not described, and we lack details such as the extracted fea- tures. However, we know they evaluated on synthetic 500-node networks and included TCP traffic flows. In EAGLE [121], the authors propose a more complex architecture to predict packet delays and loss rates simultaneously. Similar to RouteNet, the network is represented as a hypergraph that describes links, routers, and routing paths. Information between different elements is propagated through random walks across the hypergraph. According to the authors, this technique is parallelizable and effective at extracting neighborhood informa- tion, albeit it also introduces several hyperparameters to consider. Once the embeddings are obtained, a multi-head graph attention mechanism is used. While it compares well against their reference queuing model and the original RouteNet, it lacks comparison with other SotA models at the time. Then, in xNet [122], they propose another MPNN-based architecture that represents the network through a hypergraph. It considers five types of network elements, more than any other approach: nodes, queues, links, paths, and flows. Paths and flows are later used in the readout to extract the 41 performance delays, such as path packet delay or FCT. A temporal domain is also introduced by splitting the network into fixed-sized windows, achieving this earlier than RouteNet-Gauss. Overall, their evaluation shows better results than models such as Deep-Q [129] and the original RouteNet, but lacks evaluating different traffic distributions or different-sized network topologies. In GLANCE [123], a similar hypergraph definition of the network is pro- posed, considering path, node, and link embeddings, and an MPNN-like ar- chitecture. Unlike other MPNNs, GLANCE does not reuse parameters be- tween iterations in the message passing phase. This is uncommon, as while it increases the potential model expressivity, in practice, it increases training costs and usually does not result in improved performance. Also, GLANCE defines an edge graph convolutional layer when updating the node embed- dings, combining graph and spectral features. While the latter can capture expressive relationships, they too risk lower generalization to unseen topolo- gies. Moreover, GLANCE is the first model to propose the use of transfer learning, specifically, to re-train the model to new tasks quickly. It consists of fixing (a.k.a freezing) the weights of the embeddings and message passing phases, and retraining the readout function from scratch. In the evaluation, GLANCE does improve against RouteNet-Fermi, although this difference is smaller while generalizing to unseen topologies. Unlike in previous models, FlowSeer [124] processes topological and flow information separately. The topological information is sent through a GCN, while flow information is processed by a DNN with attention, trained through an encoder-decoder schema. Extracted features are then concatenated and fed to a DNN for the final prediction. While separating both types of infor- mation allows processing each with an appropriate architecture, the model cannot learn how they interact until the final DNN. In its evaluation, it does show similar or better prediction accuracy than RouteNet-Erlang, but it does not include comparisons of generalization to unseen network topologies. Next, m4 [125] proposes the use of a âflow-level simulator" based on GNNs. Specifically, their solution includes a flow generation module that generates TCP flows according to a user-specified workload. The model then uses a temporal and spatial component to update the state and predict the flowâs performance metrics, specifically FCT and throughput. The tempo- ral component is based on a GRU [127] model, and the spatial model on a GraphSage [126] model. The spatial component also uses a hypergraph definition, which considers flows and links only. Unlike RouteNet-Gauss or xNET, its temporal component is based on events (i.e., a flow starting/ending 42 in the network) rather than fixed-sized windows. This minimizes how many times the flow states need to be updated, although it makes it unsuitable for predicting metrics such as packet delay over time. m4 also proposes learning secondary performance metrics during training, such as the flowâs remaining data to retransmit, to provide the model with further information and im- prove its overall accuracy, validated in their evaluation. Finally, m4 cannot model QoS queues. 5.2.3. Other DL Models Due to GNNâs advantages, they are the preferred architecture when build- ing network models. However, authors have also experimented with other architectures and approaches. An early example is that of xWeaver [128], where authors propose work- ing Convolutional Neural Network (CNN). Specifically, its model uses two separate CNNs to process the adjacency and traffic matrices, whose results are then concatenated and joined in a DNN to predict any relevant perfor- mance (in the evaluation, they focus on FCT and throughput). While using a CNN allows for a more effective architecture than a DNN, as corroborated in its evaluation, it still raises some questions. For example, it is not clear if the method is permutation invariant âthat is, whether the nodesâ order in the traffic matrix impacts the results. Also, similar to FlowSeer, process- ing separately the topological and traffic information makes it harder for the model to learn cross-interactions. Another early approach is proposed in Deep-Q [129], consisting of train- ing a Conditional Variational Auto-Encoder (CVAE) model [130]. Both the encoder and decoder segments of the CVAE, implemented through DNNs, use the extracted traffic features as bias. These features are extracted from the traffic matrices using a Long Short-Term Memory (LSTM) [25] network. A specialized loss definition is used to train both the LSTM and CVAE. At inference time, only the LSTM and the decoder segment are used to predict the desired performance metrics. While this approach is accurate and has low inference time, it ignores the underlying network topology. Later, in [131], the authors propose the adoption of the transformer ar- chitecture [132], popular at the time due to its successful use in LLMs. They argue that having a pre-trained network performance model can be used and later fine-tuned to specific networks. They also defend that trans- formers, as a powerful sequential model, can be used to generate and use packet embeddings to make packet-level predictions. While they examine 43 some transformer-based network model prototypes, they lack comparisons against SotA models. A more robust implementation of a network transformer model can be found in DeepQueueNet [16]. It follows a modular approach: using small, cheap-to-simulate scenarios, it builds a library of DL models, each represent- ing a network device. These are implemented through a Bidirectional LSTM (BiLSTM) and a transformer model. They take as input the sequence of packet arrival times to the device and output the updated sequence after exiting the device. Ultimately, most, if not all, of the devices in the DES are replaced by the DL model counterparts. DeepQueueNet was directly inspired by MimicNet [15], a hybrid model that replaced aspects of DES simulation with DL, but, unlike it, it is not constrained to a Fat Tree topology. However, DeepQueueNetâs methodology does come with limitations. For example, as noted by their authors, it cannot model the transient state of networks and, because of the batch processing of packets, it cannot support stateful protocols like TCP. Furthermore, because of the batching, packets can be processed out of order; the authors do propose a solution, but it re- quires repeated inferences by the DL models, increasing computational cost. In addition, both the BiLSTM and transformer architectures are notoriously computationally expensive. As a result, DeepQueueNet does not appear to reduce the amount of computational effort, relative to DES. Instead, due to its implementation through libraries like Tensorflow, it is better suited to run distributively and even in specialized hardware like GPUs. Still, less computationally expensive methods, such as MimicNet, perform inference faster under the same hardware, with the difference scaling with the network topologyâs size. Finally, in [133, 134], the authors propose a two-step process to build a network model by first training it using simulated network data and then efficiently adjusting it using a small dataset of real-world network data. The objective was to utilize transfer learning to allow the model to learn from simulated samples while being effective in real-world scenarios. The model itself was to follow the Neural Processes (NPs) [27] architecture, a type of DNN that focuses on learning the inputâs latent features, and eases learn- ing. However, it also shares limitations present in DNNs, like the lack of adaptability to unseen topologies, routing configurations, and traffic profiles during training. 44 5.3. Summary While ML-based network models have existed since the early 2000s, it was not until the proliferation of deep neural network architectures, and specifi- cally GNNs, that they became so dominant. The flexibility behind these ar- chitectures allows for specialized designs for network performance modeling, allowing them to be more accurate than analytical models while performing inference at low inference costs. This makes them especially appealing for active network management, where quick, accurate predictions are required (e.g., xWeaver [128], RouteNet [109], GLANCE [123]), overtaking analytical models (discussed more in detail in Section 7). Traditional ML models also remain a viable option, as they are characterized by even cheaper inferences (e.g., CLAAP [106]). ML models are not flawless, however. Unlike simulation or analytical models, ML models are constrained to scenarios similar to those seen during training (e.g., network topologies, traffic profiles, network protocols). While this can be mitigated through clever design (e.g., model architecture, how input data is encoded), no covered approach achieves the same degree of generalization as DES. Also, while faster than DES simulators, ML models usually cannot offer the same level of granularity in their predictions. Those that do, like DeepQueueNet [16], do so at the cost of their low inference costs. 6. Hybrid Approaches In this section, we discuss network models that combine two or more of the previously discussed approaches, summarized in Table 5. This has the aim of complementing their advantages and minimizing the pitfalls. By nature, these models are the most heterogeneous in the ways they approach the model. 6.1. Model-tuned Emulation for Performance Modeling Network emulators are powerful tools to validate and understand network dynamics. Unlike simulation, which focuses on defining the network state and understanding how it is updated, emulation replicates the network behavior and its devices through software. However, emulation also replicates through software certain behaviors that were originally executed by hardware logic. This distorts the time taken to perform each of these operations, presenting serious limitations when predicting the performance of the networks. 45 Model Main Type Secondary Type Input Scope Output Scope Traffic Type Performance Metrics Evaluation Pantheon[40] Networkemulator(Mahimahi[137]) Bayesianoptimization Full network scenarios Packet- level Any Full packet path information Real data iBox [41] Network emulator witha queuemodel Bayesianoptimization Full network scenarios Packet- level Any Full packet path information Real data Prophet[138] NUManalyticalmodel [94] Gradientdescent Full network scenarios Flow-level TCP 1 Flow throughput Simulated data DeepTMA[139, 140] NC(TMA [35]) GGNN [23] Full network scenarios Flow-level (temporal) Non-specific Worst-bound packet delay Simulated data [39] GraphSage [126] NC(TFA [7, 8],SFA [30]) Full network scenarios Flow-level UDP Mean, min, max, 90th and 99thpercentile packetdelays Testbed data QT-RouteNet[38] RouteNet[109] M/M/1/Bqueue model Full network scenarios Flow-level UDP Average packet delay Simulated data GNNetSlice[141] RGCN [32] Unspecified QT model Full network scenarios Flow-level UDP Average packet delay, jitter, andloss Simulated data 1 TCP flavors supported by Srikantâs model [142] 46 QINN [143] DNN M/G/1 queue model Traffic- matrix scenarios Flow-level UDP and TCP (non-specific) Avg. packet de-lay, throughput Simulated data [42] ns-2 [28] Flow queueingmodel [74] Full network scenarios Packet- level UDP and TCP 2 Full packet pathinformation Simulated data MimicNet[15] ns-3 [29] LSTM [25] Full network scenarios Packet- level Any Full packet path information Simulated data m3 [144] flowSim [145] Transformer (LLama2 [146]) Full network scenarios Flow-level UDP and TCP (DCTCP, TIMELY, DCQCN, HPCC) 99th percentileFCT Simulated + Real data CausalSim[43] Tracesimulation Causal DNN Full network scenarios Packet- level Any Full packet path information Simulated data Sim2HW[44] OMNET++[36] GraphSage[126] Full network scenarios Flow-level UDP Min, 25th, 50th, 75th, 90th, 99th,99.9th, 99.99th,99.999th per-centile packetdelays Testbed data 2 Secondary model accounts only for TCP. Table 5: Summary of hybrid network performance models 47 The authors of Pantheon [40] identified this issue and proposed a model to fine-tune emulation software to track traffic performance accurately. It consists in fine-tuning emulation parameters, like propagation delay, using Bayesian optimization. Specifically, this is a process where the parameters were adjusted, evaluated using captured internet traces, and updated ac- cording to their error. This was done using the Mahimahi [137] emulation software. Their evaluation showed a tenfold decrease in prediction error. However, this approach remains limited, due to the small number of ad- justable parameters, resulting in the error rates averaging at 17% for the tested traces, and the cost of emulating the different scenarios repeatedly. A similar approach is that of iBox [41]. iBox models the network as a sin- gle bottleneck link with a FIFO, drop-tail queue. iBox considers two models, discriminating between âreactive" and ânon-reactive" cross traffic. They de- fine non-reactive traffic as those flows whose performance is not influenced by changing the specific congestion control protocol, reactive otherwise. While the non-reactive cross traffic can be modeled directly from parameters ex- tracted from the network traces, the reactive cross traffic parameters are learned through Bayesian Optimization and real traffic traces, as in Pan- theon. The queue model is executed within a network simulator or emulator to be evaluated; in their evaluation, the authors specifically used ns-2. iBox ultimately shares similar benefits and limitations to its predecessor: by being built with real traffic traces, it attempts to minimize the impact of training with simulated traces [147, 148, 59]. However, the combination of Bayesian optimizationâs high computational cost and the modelâs simplicity may limit its practicality in real-world deployments. 6.2. ML + Analytical Hybrid Models Generally, both ML and analytical models offer similar strengths and weaknesses âi.e., quick inference times but less accurate than DES. While it may be counterintuitive to combine the two, successful applications can still be found in the SotA. An early example is Prophet [138], where they used ML to solve the NUM model [94]. In the original NUM paper, the authors aimed to maxi- mize TCP throughput, but their initial ideal model required prior knowledge of each flowâs utility. In Prophet, however, they can approximate the ex- pected utility using Srikantâs unifying model [142]. Although this too relies on another unknown, the scaling factor, Prophet approximates it through sampling and gradient descent. Sampling is done efficiently, approximating 48 the flow parameters, and grouping flows to reduce the number of them to consider. Conversely, these modifications limit the modelâs applicability. For example, the flow grouping is designed assuming a Clos topology. Another approach is to use ML to improve the reasoning of an analytical model. In [139], a GNN model is used to predict the best tandem decompo- sitions to be used by their NC model. By acting as a heuristic, the GNN can improve the results of the NC model without incurring a significant penalty in inference time. Furthermore, the GNN model does not need to be per- fectly accurate for the NC model to benefit from it. The authors expanded DeepTMA in [140], to allow the generation of decompositions, as well as per- forming feature analysis to understand which are the most significant features of the GNN model. While this approach reliably increases the NC modelâs accuracy, ultimately, it cannot address the inherent limitations present in NC models (e.g., assuming feedforward networks). In contrast, in [39], the authors invert the dynamic, instead using the upper bounds gathered from an NC model as an additional input to a GNN model tasked to predict the performance metrics. Their analysis leveraged a GraphSage [126] model, a generic GNN architecture, but its findings may be generalized to more specialized GNN architectures. They have also con- firmed, as expected, that tighter NC bounds increase the accuracy of the resulting GNN model. A similar approach was followed by the authors of QT-RouteNet [38]. In this case, the authors use a QT model of the network âa M/M/1/B modelâ to extract flow and link features, which later are used as input by an RouteNet [109] model. Doing so allowed it to generalize to topolo- gies much larger than training: it was trained on topologies up to 50 nodes large, and evaluated in topologies ranging from 51-300 nodes. Similarly, GNNetSlice [141] also introduces network slicing information and approx- imate QT predictions, such as the expected maximum queuing delay and packet loss rate, as inputs to its model. The model itself is a Relational GCN (RGCN) [32] designed to measure the impact of network slicing on performance. In its evaluation, it outperformed RouteNet-Fermi [17] when predicting the average packet loss rate, delay, and jitter. Later, in Queue-Informed Neural Network (QINN) [143], integration is expanded to include a queue model in the modelâs loss function. In summary, a DNN model predicts both the average queuing delay and the throughput; the latter is then used by a M/G/1 queue model to obtain a second queuing delay prediction. The loss function computes the loss over both predictions. 49 While the authors have used a DNN, this approach is compatible with other N architectures. Ultimately, all of these approaches are a reliable way of improving the modelâs accuracy, but they cannot resolve MLâs inherent limitations. 6.3. Accelerated DES An alternative hybrid approach for network modeling, and arguably one of the most popular nowadays in the SotA, consists of reducing the compu- tational cost of DES by replacing some elements with a faster alternative. The main objective is to maintain DESâs benefits (mainly its accuracy) while minimizing its computational cost. The first model to attempt this was in [42], where the authors combined a DES simulator (ns-2) with the fluid model in [74]. The fluid model only covered TCP flows in the networkâs core. The paper introduces rules on how packets are updated when they cross the core, according to the values of the resolved fluid model, along with synchronization rules to avoid the DES and fluid modelâs states from diverging. Limitations include the fluid modelâs increased error rate and only applying to TCP flows. Furthermore, the translation between fluid and simulated traffic can result in predictions that generally hold but do not offer sufficient granularity. For example, the fluid model may predict accurately that a percentage of packets will drop at a given time, but cannot exactly predict which packets are dropped; instead, these will be selected at random. It will take nearly two decades for a new iteration of this idea to be proposed, which eventually does so in the form of MimicNet [15]. Rather than an analytical model, MimicNet uses an LSTM model to replace parts of the network topology in the DES. The approach exploits the symmetry present in fat tree topologies, commonly used within data centers: first, it simulates a two-branch fat tree topology to train its LSTM model. During inference, it only simulates a single branch, while the rest are replaced with LSTM replicas. The LSTM models predict whether packets in the replicated branches are dropped or forwarded according to their expected behavior. By leveraging the symmetry of the topology, MimicNet remains accurate and computationally efficient. However, this results in some rigid assumptions. First, the network is assumed to be a failure-free fat tree topology, with congestion only present in the fan-in towards the flowâs destination. Second, traffic patterns are expected âscale proportionally to the size of the network", 50 as otherwise faithful models cannot be trained using the smaller, two-branch topology. Inspired by Parsimon [57], the authors of m3 [144] propose splitting the network simulation into path-level simulations. Specifically, paths are sim- ulated separately, considering in each of them the set of foreground and background flows. Foreground flows are simulated in parallel and quickly using flowSim [145], while the impact of background flows is approximated using a LLama2 transformer model [146]. These results, as well as additional scenario context (e.g., congestion algorithm), are concatenated and fed to a DNN to obtain the corrected approximations of the flowâs FCT. The main advantage of m3 relative to Parsimon is that assuming path-level is a weaker assumption than link-level independence. Relative to its inspiration, m3âs evaluation showed it to be more accurate and quicker inference times, de- spite including the relatively large LLama2 model. However, unlike most simulators, it does not maintain packet-level visibility. Instead, like Parsi- mon, m3 is designed for aggregated tail-prediction performance metrics, such as worst-case TCP throughput. Finally, its support of congestion control is based on being parametrized and added to the input features of its final DNN in its architecture. Consequently, it only supports those protocols seen during training. 6.4. Simulation with DL-Enhanced Accuracy As we discussed, while network simulation is perceived as the most accu- rate approach for performance modeling, it is still subject to some inaccura- cies [58, 40]. Consequently, we have seen some approaches that attempt to use DL to enhance the simulationâs accuracy to better match reality. Unlike the models in Section 6.1, these are applied to simulators, not emulators, and they are complemented with DL models. One example of this is CasualSim [43]. In it, they use trace simulation, a faster yet more inaccurate alternative to DES, and instead use ML to improve its accuracy. Trace-simulation is a variant of DES where only a subset of the system is simulated, while the other segments are replaced with traffic traces. However, it assumes that the tracesâ contents are independent of the rest of the simulation, which rarely holds. Consequently, CasualSim proposes the use of a causal DNN model to adapt the traces according to the system behavior, improving accuracy. However, trace simulation is meant to simulate the impact of specific small changes for âwhat-if" scenarios. Larger 51 changes result in fewer elements being replaced by traces, hence becoming increasingly similar to standard DES. Recently, in Sim2HW [44], the authors use an expanded GraphSage [126] model to correct the network performance predictions given by OMNET++ [36]. To train the model, simulated network scenarios were replicated in a testbed to obtain their ground truth. While this approach may enhance the simu- latorâs accuracy in replicating real-world traffic, it does not address DESâs main issue: its high computational cost. 6.5. Summary Ultimately, hybrid models are characterized by their diversity and prac- tical nature. By combining existing, proven approaches, the authors of these approaches obtain stronger network models. This includes expand- ing emulation with network models to support performance modeling (e.g., Pantheon [40] and iBox [41]), applying ML to accelerate DES (e.g., Mimic- Net [15] m3 [144]) or correct its outputs (e.g., Sim2HW [44]), using ML-based heuristics to improve NC models (e.g., DeepTMA [139, 140]), and conversely using NC and QT to improve ML model training (e.g., QINN [143]) or to provide additional input information (e.g., [39], QT-RouteNet [38], GNNet- Slice [141]). The biggest benefits of these approaches are the ability to combine the strengths of both approaches. For example, when using ML to accelerate DES, ideally, the resulting model can retain DESâs accuracy and granularity while benefiting from lower computational costs. However, this comes at the risk of inheriting the weaknesses as well âfor example, any hybrid approach with an ML-model will require such to be trained. 7. Discussion on Identified Trends and Challenges within Network Performance Modeling In this section, we discuss the trends and challenges identified in current network performance models. This section is also meant to expand on earlier discussions [147, 148, 59]. 7.1. Balance Between Accuracy, Resolution, Applicability, and Inference Cost An ideal network performance model should be accurate, expressive (i.e., granular predictions, ideally packet-level), applicable in general sce- narios, and with a low computational cost. In practice, however, current network performance models cannot guarantee all of these properties. 52 ApproachAccuracy Expressiveness ApplicabilityComputational Cost Simulation DES HighPacket-levelGeneral High (and sequential) PDESHigh QT Discrete Low Flow-level Specific TCP version Low Fluid Flow-level (temporal) NC ADNCMediumFlow-level Feed-foward networks Medium ODNCHigh(temporal)High ML Shallow ML Medium Flow-levelOn trained topologies Low (temporal andand traffic profiles DLHighnon-temporal) On trained traffic pro- files Medium Hybrid approaches ML+AnalyticalHighFlow-level On trained traffic pro- files Medium Accelerated DES High Flow-level/ Packet-level On trained traffic pro- files; topology support varies. High Table 6: Summary of current network performance modeling approaches. This is reflected in Table 6, where the different approaches are summa- rized and qualitatively compared. On the one hand, DES tends to be the preferred option for network modeling, but its cost makes it unfeasible in many scenarios. PDES addresses this, not by reducing its cost, but by allow- ing for the simulation to be spread across more cores. This does allow it to simulate larger scenarios, but requires higher amounts of computing power, which remains impractical. As a result, research in DES and PDES focuses on reducing the cost while maintaining its other benefits. On the other hand, both analytical and ML models tend to be computationally inexpen- sive. Instead, research on these models focuses on improving their accuracy, expressiveness, and the scenarios in which they are applicable while retaining the low computational cost. Hybrid approaches, on the other hand, try to split the difference by syn- thesizing different approaches. For instance, accelerated DES methods seek to reduce computational cost while preserving the strengths of traditional DES. DL techniques have also proven flexible, as surveyed examples include quicker models with reasonable accuracy (e.g., RouteNet-Fermi [17]) and more complex, complete models akin to DES (e.g., DeepQueueNet [16]). However, current approaches still fall short of reaching all four character- istics. For example, MimicNet [15] is only applicable in fat tree topologies, while m3 [144] loses packet-level visibility and can only predict high percentile FCT. Furthermore, approaches such as ML+Analytical Hybrid Models tend to offer small yet significant improvements in their accuracy but do not ad- 53 dress other fundamental constraints present in either approach. As a result, the optimal approach will depend on its expected application. If time and computational resources are not a constraint, DES remains the best option. However, if the network performance prediction is expected to be integrated in a more complex, time-critical application (or simply a quicker, approximate prediction is desired), an analytical or ML model is better suited. Alternatively, a model that is meant to be applied only to a specific network with a static topology may not need the same degree of applicability that a general-purpose approach like DES. Ultimately, as also argued in [148], researchers must consider their use case when deciding which measurements to use as input, which aspects of the network should be modeled in this use case, and which properties are most relevant. The differences in approaches are also reflected in how the field tries to develop better network models. While some researchers focus on reducing the costs of the heavier, more accurate models, others try to improve the accuracy of the more efficient ones. Furthermore, it is not unreasonable to believe that such an âideal" model is impossible to build to begin with, as the different features can impede others. For example: ⢠An expressive model should predict the behavior of individual packets, yet their amount in modern networks is measured in the billions [58]. Hence, obtaining packet predictions, without aggregation or summa- rization, will be inherently expensive by sheer scale. ⢠Similarly, aggregation also implies losing information as the sequences of packets get shortened to a fixed set of values, resulting in a potential loss of accuracy. ⢠Analytical and statistical models rely on assumptions for them to be accurate. However, these may constrain the range of scenarios they can be applied to. Nonetheless, without such assumptions, the mod- els fail to characterize network traffic and its behavior (no-free-lunch theorem [149]). 7.2. The Dominance of DES and the Surge of GNNs Traditionally, DES has been regarded by network operators as the gold standard for network performance modeling. This is exemplified by the suc- cess of major DES simulators like ns and OMNET++, as well as the fact that 54 most non-DES network performance models are compared using or against simulated data. Referring back to Figure 1 in the introduction, simulation is the only type of model that has had constant attention over the last three decades. This can be explained by the fact that simulation is both one of the most accurate options and capable of offering packet-level predictions. However, since 2018, we have seen a surge in DL network performance models. This is in part due to the success of the GNN architectures. Their design exploits the relational information in computer networks to their ad- vantage, proving to be accurate and computationally inexpensive. While they do not offer packet-level granularity, they can be augmented to include a temporal resolution [58, 122, 125]. This has resulted in their dominance as the most used DL architecture when building network models: 17 out of the 29 (â 58%) pure ML models identified in the survey are based on GNNs. They are also quite relevant in hybrid approaches: 5 out of the 12 hybrid models identified included a GNN model. Note that this prevalence is not universally shared across the entire com- munity. Let us consider models published since 2018 in ACM SIGCOMM and IEEE INFOCOM, the two CORE A* conferences regarding computer networking. On the one hand, the IEEE INFOCOM does reflect the preva- lence of GNNs, with two out of three models accounted for being GNN- based [17, 122] and the remainder one being a hybrid method involving ML [138]. On the other hand, ACM SIGCOMM instead prefers PDES and similar methods: out of the seven models published since 2018, three models are PDES proposals [18, 53, 56], and another two models are DL-accelerated DES hybrid approaches [15, 144]. Of the remaining two models, only one is a GNN [110]. The other, DeepQueueNet [16], is a transformer-based model whose design mimics DES reasoning, down to reasoning over individual pack- ets. These discrepancies show that different voices in the communities may show preferences in which aspects of network performance simulation they prioritize, hence preferring approaches whose strengths align with them. 7.3. Reduced Interest in Analytical Models While there has been a rise in DL-based models, specifically the GNN architectures, it has come at the cost of slowing the development of newer analytical models. Out of the models we have surveyed, only one purely analytical model was published in the last 5 years [66], with the previous one being published in 2017 [35]. We have identified some potential reasons why. 55 First, the most straightforward explanation is the fact that ML (and DL) models offer similar benefits while outperforming analytical models. At first, the main difference that analytical models offered against DES was their re- duced computational cost, at the cost of less expressive and accurate results. Nowadays, ML models also offer accurate and computationally inexpensive predictions, hence placing themselves in direct comparison against analytical models. Second, unlike ML, analytical models try to explicitly define complex network behavior through sets or systems of equations. ML models either treat networks as black boxes and try to predict their performance through regression (e.g., [37] and CLAAP [106]), or explicitly represent some exist- ing dependencies within the network but still rely on the training process for them to be completely developed (e.g., RouteNet [111]). By contrast, analyt- ical models must be completely formulated by their creators, which involves defining their assumptions and mathematically proving their validity or error bounds. In turn, this makes analytical models more rigid, less future-proof, and arguably harder to build overall. An example of this is how different approaches support multiple versions of TCP simultaneously. This is an important aspect for network models, as TCP implementations evolve, and it is not uncommon for several versions to co-exist in the same network [147]. In analytical models, authors either assume a âgeneric" TCP version, which results in inaccuracies as it fails to capture the differences between implementations [78, 71, 72], or are forced to re-formulate segments of the model for each version they support [70, 74]. In contrast, DL models that support multiple TCP versions usually differentiate between versions through a one-hot encoded vector [119, 125]. This means that DL models can be expanded to fit more TCP versions easily, as long as the authors have the recorded scenarios to train them with. There is also the fact that, as new DL architectures keep being developed, researchers will continue to explore their potential as network performance models, as it happened recently with the transformer architecture [131, 16]. Altogether, this can explain why the research into new analytical models has slowed down, and instead, this effort has moved into the development of ML models. 7.4. Adapting to Changing Networks One of the biggest challenges of network performance modeling identified early on was that of describing the internet as an âimmense moving target" 56 [147, 59]. They identified the dynamic nature of networks, how they change over time in terms of traffic patterns, usage, and implemented protocols, and how these could be a challenge to network models at the time. This remains an ongoing challenge: since the 2000s, internet usage has continued to increase, data centers rely on newer TCP variants like DCTCP [34] and DCQN [21], and wireless networks are more common and complex. At the time, solutions proposed to address this challenge were based on the modeling approaches prevalent at that time. Analytical models were seen as the most vulnerable, as they tend to rely more on network assumptions or, in the case of queuing and fluid models, they were designed with a given TCP version in mind. A solution proposed back then was searching for invariant properties âaspects or properties that remain constant over different network topologies, sizes, and usages [147, 59]. Examples include the self-correlation in packet inter-arrival distributions, or the heavy-tail distributions present in metrics such as packet delay, RTT, or FCT. Another solution proposed was the push for modular, interoperable mod- els [148]. The idea was to avoid building monolithic network models capable of individually addressing any scenario. Instead, it proposed building net- work models for them to be interoperable, that is, for them to be combined and fed to each other. This allows models to be gradually updated to newer developments, like newer TCP versions. This approach is better suited for DES simulators, as these can be expanded to cover new protocols and de- vices as they are released. Open-sourced simulators like ns [28, 29] and OM- NeT [36] have remained updated thanks to the community. Furthermore, we have modular PDES like SimBricks [53] and SplitSim [54] whose modular- ity enables their coverage of network features as well as their parallelization. Finally, DL models do offer new ways to address this issue, we will cover it later in Section 8.3. 7.5. Simulation-Dominated Evaluation Another trend in network modeling is the prevalence of using simulated data in the evaluation. This fact is reflected in Figure 3, which shows how models across the different approaches are evaluated. Overall, it shows that the use of simulated data dominates, used in over half of the surveyed models, and is the most used across all the approaches except simulation itself; even across simulators, comparing against other simulators remains the preferred evaluation choice. This is because most simulators surveyed are published through white papers, which describe the simulation implementation but 57 Simulation Analytical Models ML Models Hybrid Approaches Total 10 10 5 21 17 8 51 1 9 2 12 2 3 3 8 13 1 14 Analytical Simulated-data Testbed-data Real-data No evaluation / Other Figure 3: Evaluation categories across different model types. If a model is evaluated with multiple categories, they are categorized in the following priority: real data, testbed data, simulated data, and analytical. otherwise do not measure their accuracy. Otherwise, we see a minority of models being evaluated with testbed or captured data in ML and hybrid approaches, while another significant minority of samples are just evaluated analytically in the case of the analytical models. Overall, there are strong reasons for this. First, captured data is scarce and not always available. Unlike it, simulated data can be generated to cover any desired scenario, allowing for more diverse datasets. Second, captured data may also be limited by the features that the dataâs authors were able to capture, while in simulation, the entire state of the network and traffic is present. Furthermore, testbed networks require a monetary cost to set up and later upgrade (e.g., changing devices). Meanwhile, simulation software can be run on generic computing devices without additional hardware. How- ever, simulation has several disadvantages, as commented back in Section 3. First, its high computational cost limits the size of the networks or traffic intensities used in the evaluation. Hence, whenever the model is applied to these challenging scenarios, it may perform worse than expected. There is also the issue where simulation may not cover specific protocols and network devices, or without the required accuracy [59, 60, 40, 58]. 58 7.6. Heterogeneous Approaches, Heterogeneous Evaluations Another challenge present in network performance modeling is a lack of common evaluation procedures. We believe that this is due to the heterogene- ity of modeling approaches compounded by the scarcity of public datasets. The differences in network performance modeling approaches allow for the creation of models with different strengths and goals. Such versatility per- mits network operators to choose the modeling approach that best fits their needs. First, models may differ on the performance metric they measure, which depends on the traffic type they are modeling (e.g., traffic from a spe- cific protocol like TCP). This also influences what data they take as input, as some use solely traffic traces, while others can include the entire network in their reasoning. Later, some models can be only applicable under certain constraints (e.g., NC only applicable to feed-forward networks, or Mimic- Net [15] only to fat tree topologies), which also limits common scenarios where they can be compared to other models. Even when considering the same metric, the granularity of their outputs may also condition how models are evaluated. For example, models that predict on a packet-level, or even a flow-level with a temporal component, must see their predictions aggregated to be compared against models offering flow-level predictions. Furthermore, even comparing packet-level outputs against each other may be complicated. For example, one model may predict a given delay for a packet that, according to the ground truth, was lost. This, in turn, makes us rely on error metrics like the Wasserstein metric to compare the distribution of the predictions. While useful, such metrics lack the intuitiveness behind the obtained result. That is, unlike metrics like the Mean Absolute Percent- age Error that can be easily understood, there is no clear way of interpreting whether a given Wasserstein metric can be regarded as a âgood" or âbad" re- sult. At most, it can be used to compare models, knowing that lower values mean closer predictions to the ground truth. Note that these difficulties also apply to models that offer flow-level pre- dictions with a temporal component. This may be exacerbated by the fact that these models may consider their temporal component under different scales (e.g., predictions every second versus every millisecond). Even worse, models may define their temporal components differently. For example, while RouteNet-Gauss [58] may consider fixed-length windows, the temporal com- ponent in m4 [125] is event-driven. Finally, all of these difficulties are worsened by the lack of publicly avail- able network data. This is the case for several reasons. In the case of real- 59 world captured data, only a few groups and companies have access to such, and the capability to capture it. Furthermore, publishing real data from real users may pose privacy risks and requires anonymization procedures for it to be safe to be made public. Alternatively, testbed networks are rare due to their costs; hence, by extension, published datasets will also be rare. 8. Future Directions and Opportunities In this section, we follow up on the previous discussion with our prediction on future research directions for network performance modeling. This is based on our expected evolution of current trends and how current challenges may be addressed. 8.1. Consolidation of PDES and GNNs Models First, from the conclusions obtained from Sections 7.2 and 7.5, we can derive that DES is one of, if not the most desirable, modeling approaches available to network operators nowadays. Unsurprisingly, lately, there has been a push by researchers to address the challenge of PDES design. Hence, we believe that PDES research will continue to consolidate its position as the new âbaseline" method, replacing traditional (single-process) DES sim- ulators. This means reducing the synchronization overhead while retaining correctness. We believe that the increased availability of computing power [3] means that computational efficiency will not be as much of a priority com- pared with the ability of the PDES to exploit the resources available. The most recent PDES surveyed, NSX [56], exemplifies this, proposing a highly distributed simulation that can run in the same specialized hardware used to train AI models. By analyzing the SotA, we can also conclude that DL models, and specifi- cally GNNs, are well-positioned to become the main alternative to simulation. They can be applied to scenarios where PDES cannot, such as those with restrictions on computing resources available. Then, for the remaining sce- narios, DL models are magnitudes of times quicker than PDES while also benefiting from parallelization and specialized hardware thanks to libraries like Tensorflow and Pytorch. Among DL architectures, specialized GNNs for networking have proved to be the most effective, being both cost-effective, accurate, and more robust than their other alternatives. However, there is still progress to be made for GNNs. For example, support for congestion control algorithms [119, 118] or the temporal compo- 60 nent [58] is still fairly recent. Also, current models can only faithfully predict traffic patterns seen during their training. Ultimately, addressing these issues will increase the number of scenarios GNNs can be applied to and establish them as a reliable alternative to DES. 8.2. Analytical Models Enhancing DL Models In Section 7.3, we discussed how research into analytical models is getting reduced attention, as ML and DL network models are proving to be more cost-effective. However, we have seen how analytical models are still being used in conjunction with other techniques. An example of this is how both QT and NC models have been used as heuristic input to be fed to a DL model to improve their accuracy [39, 38]. Recently, studies have also shown that they can be used to define more informed loss functions, further improving the training process [143]. Ultimately, analytical models still offer inexpensive, good approximations of the expected performance that more complex network models can later re- fine. The proposed approaches also benefit from the fact that they can be applied independently of the underlying ML architecture, easing their imple- mentation. Further research in this area can lead to improved ML models that retain their cost-effectiveness. This includes studying other aspects in which the analytical model can be integrated into the DL architecture be- yond the input features and loss functions, as well as how to incorporate more complex analytical models without incurring excessive computational costs. 8.3. ML as a New Tool for Evolving Networks Section 7.4 discussed the challenge of the ever-changing nature of net- works, and how to address models becoming outdated because of it. Pro- posals in the past include models focusing on true invariant properties of networks or designing systems of interoperable models. In addition to these proposals, we believe ML, and specifically DL, has un- locked a new way to handle changing networks. Unlike analytical models or simulations, an ML model does not explicitly encode the network dynamics. Instead, it learns these dynamics from its training data. Hence, under the assumption of having an appropriate ML architecture to learn such network dynamics, such as a GNN, it is reasonable to believe that the architecture itself does not need to be modified to be adapted to changes in the network. 61 Instead, the ML model would have to be re-trained, a process that, while re- quiring some computational effort it no longer requires the expert knowledge required to adapt an analytical model, implement a simulator, or design an ML architecture. We refer to this new approach as design once, train as necessary, and it has already been proposed in papers such as [131]. Besides adapting to evolving network conditions, it would also allow for designing a general ar- chitecture valid for many specific use cases, depending on how it is trained. Furthermore, re-training may be less costly than training from scratch by exploiting transfer learning, as done in existing works [123, 133, 134]. At its best, this approach allows the advantages of using a universal design for building network performance models, while making their implementation specific for each use case, adapting to its necessities. Nonetheless, this approach still has some drawbacks that future research must address. First, with the current formulation, the model would still re- quire new traffic measurements for its readjustment. While transfer learning would reduce the amount of data needed, it can still be a costly process. Also, until the model is adjusted, it cannot be expected to work accurately. Hence, DL models should still be designed to be as generalizable as possible, to reduce the amount of retraining to be done. Another risk is the gradual degradation of the modelâs accuracy intro- duced by minor changes, rather than a single significant change. The issue with this is that the gradual degradation may be harder to identify, and hence, the operators may be working with an inaccurate model without re- alizing it. This may be adjusted with a continuous model evaluation, but requires periodic network measurements. 8.4. Data Center-Centric Designs The rise in data center demand, and its focus on ML-related workloads, is an opportunity to develop more specific, data center-centric network models. Specifically, data centers already share common, well-researched topologies (e.g., Fat Trees [150]), and currently it is expected that future demand will be mainly due to the training and usage of Large Language Models or similarly large DL models [3]. Altogether, most wired network scenarios in the future will likely represent networks with similar topologies, hardware, and even traffic patterns as they will be dedicated to the same ML-related use cases. Consequently, this homogenization introduces common properties across data center networks. These can be leveraged, in the same way as other 62 invariant properties, to simplify model design without compromising model accuracy. While such models are highly specialized, given the rising demand and importance of data centers, it is a sensible trade-off. Among the surveyed models, we have already found models that do ben- efit from the increased demand in data centers. MimicNet [15] is a powerful network model, being accurate, cost-effective, and granular, but only ap- plicable to Fat Tree topologies. NSX [56] is a network simulator that is purposefully built to take advantage of modern data centers â that is, being designed to run concurrently in multiple GPUs. 8.5. Better Usage of Simulation Data for Training Real-World Models Back in Section 7.5, we discussed the prevalence of DES in the evaluation of network models and the issues arising from doing so. It is worth noting that evaluating models (and training them in case of ML-based ones) on simulated data may not lead to accurate results when addressing real-world traffic. Hence, future work must find ways to reduce this discrepancy. Currently, one way this may be addressed is by improving on DES itself. For example, more efficient PDES simulators can be used to simulate scenarios too large for traditional DES to handle. There is also work like [44] where the DESâs output is corrected using a surrogate ML model. Another popular approach, specifically when building ML models, is fram- ing the discrepancies between simulation and reality as a transfer learning problem. Transfer learning is a series of techniques meant to exploit trained models for a given task to assist in the training of models for a second, re- lated task. In this case, transfer learning would consist of using ML models trained with simulated data to assist models to be applied to real-world traf- fic. This allows for the latter to require fewer samples to build and benefit from additional accuracy. Among the surveyed works, in [133, 134] simu- lated samples are effectively used through transfer learning, but it relies on a specific architecture that benefits from it. In the recently published [151], transfer learning was successfully applied to a RouteNet-Fermi [17] model. 9. Conclusions In conclusion, this survey analyzes the evolution of network performance modeling over the last decades. We have identified 95 unique network per- formance models spread across multiple conferences and journals. By iden- tifying the taxonomy of modeling approaches, we can gain a deeper under- 63 standing of the evolution of priorities within the research and professional community. For example, we observed an evolution in preferred methodolo- gies, as models have transitioned from analytical models to ML and hybrid approaches. From the surveyed models, we have recognized the properties sought af- ter by network operators: accuracy, expressiveness (the level of detail in the results), applicability in any plausible scenario, and low computational cost. While different approaches focus on one or several of these properties, no surveyed network performance model can achieve all of them simultaneously. Admittedly, it may be impossible for all of these properties to be reached simultaneously, as they impede each other. For example, accurate and ex- pressive models tend to be more complex, which will be more costly. Consequently, this leads to the heterogeneity and diversity of the available approaches in network performance modelingâs SotA. On the one hand, such heterogeneity allows the design of specialized models, allowing researchers to optimize those properties that may be most relevant to the scenario at hand. On the other hand, it also makes the comparison between approaches harder, which is then compounded by the limited availability of public net- working datasets. We have also discussed other open problems in network performance modeling. First, we have the issue of ever-evolving networks, a problem posed over 20 years ago, which still challenges the ability to build models applicable to future networks. Second, the majority of the identi- fied network performance models rely on simulated data for their evaluation, which may compromise their expected effectiveness when applied in real- world scenarios. Finally, we have identified potentially fruitful research directions that are just starting to be explored. ML-based models and transfer learning are a promising approach to address changing networks. Advances in PDES may result in feasible simulations of large network topologies. Furthermore, we expect that other trends, like the increased demand for data centers, will shape future research. Acknowledgments This publication is part of the I+D+i project titled BLOSSOMS, grant PID2024-158530OB-I00, funded by MICIU/AEI/10.13039/501100011033/ and by ERDF/EU. This work is also partially funded by the Catalan Institution for Research and Advanced Studies (ICREA). Carlos GĂźemes is funded by 64 the AGAUR-FI ajuts (Grant Ref. 2023 F-1 00083) Joan OrĂł of the Sec- retariat of Universities and Research of the Department of Research and Universities of the Generalitat of Catalonia and the European Social Plus Fund. CRediT authorship contribution statement Carlos GĂźemes-Palau: Conceptualization, Investigation, Visualiza- tion, Writing - Original Draft, Writing - Review and Editing Miquel Ferriol- GalmĂŠs: Writing - Original Draft, Writing - Review and Editing Jordi Paillisse-Vilanova: Writing - Original Draft, Writing - Review and Edit- ing Pere Barlet-Ros: Writing - Review and Editing, Supervision Albert Cabellos-Aparicio: Supervision, Writing - Review and Editing, Funding acquisition Declaration of competing interest Carlos GĂźemes-Palau reports financial support was provided by Spain Ministry of Science and Innovation. Miquel Ferriol-GalmĂŠs reports financial support was provided by Spain Ministry of Science and Innovation. Jordi Paillisse-Vilanova reports financial support was provided by Spain Ministry of Science and Innovation. Pere Barlet-Ros reports financial support was provided by Spain Ministry of Science and Innovation. Albert Cabellos- Aparicio reports financial support was provided by Spain Ministry of Science and Innovation. Carlos GĂźemes-Palau reports financial support was provided by Generalitat de Catalunya Ministry of Research and Universities. Carlos GĂźemes-Palau reports financial support was provided by European Social Plus Fund. Pere Barlet-Ros reports financial support was provided by Cata- lan Institution for Research and Advanced Studies. Albert Cabellos-Aparicio reports financial support was provided by Catalan Institution for Research and Advanced Studies. If there are other authors, they declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. Data availability No data was used for the research described in the article. 65 References [1] J. Pedro, J. Santos, J. Pires, Performance evaluation of integrated otn/dwdm networks with single-stage multiplexing of optical channel data units, in: 2011 13th International Conference on Transparent Op- tical Networks, 2011, p. 1â4. doi:10.1109/ICTON.2011.5970940. [2] Abeliene network [archived in wayback machine]. URL https://web.archive.org/web/20120324103518/http: //w.internet2.edu/pubs/200502-IS-AN.pdf [3] IEA, Energy and AI (Jul 2025). URL https://w.iea.org/reports/energy-and-ai [4] J. Popoola, R. A. Ipinyomi, Empirical Performance of Weibull Self- Similar Tele-traffic Model, International Journal of Engineering and Applied Sciences 4 (8) (3 2017). [5] M. Alasmar, R. Clegg, N. Zakhleniuk, G. Parisis, Internet Traf- fic Volumes are Not GaussianâThey are Log-Normal: An 18-Year Longitudinal Study With Implications for Modelling and Prediction, IEEE/ACM Transactions on Networking 29 (3) (2021) 1266â1279. doi:10.1109/TNET.2021.3059542. URL https://ieeexplore.ieee.org/document/9361437/ [6] J. R. Jackson, Jobshop-like Queueing Systems, Management Science 10 (1) (1963) 131â142. URL http://w.jstor.org/stable/2627213 [7] R. Cruz, A calculus for network delay. I. Network elements in isola- tion, IEEE Transactions on Information Theory 37 (1) (1991) 114â131. doi:10.1109/18.61109. URL http://ieeexplore.ieee.org/document/61109/ [8] R. Cruz, A calculus for network delay. I. Network analysis, IEEE Transactions on Information Theory 37 (1) (1991) 132â141. doi:10.1109/18.61110. URL http://ieeexplore.ieee.org/document/61110/ [9] Q. Mao, F. Hu, Q. Hao, Deep learning for intelligent wireless networks: A comprehensive survey, IEEE Communications Surveys & Tutorials 20 (4) (2018) 2595â2621. doi:10.1109/COMST.2018.2846401. 66 [10] Y. Shi, L. Lian, Y. Shi, Z. Wang, Y. Zhou, L. Fu, L. Bai, J. Zhang, W. Zhang, Machine learning for large-scale optimization in 6g wireless networks, IEEE Communications Surveys & Tutorials 25 (4) (2023) 2088â2132. doi:10.1109/COMST.2023.3300664. [11] R. Verdecchia, L. Scommegna, B. Picano, M. Becattini, E. Vicario, Network Digital Twins: A Systematic Review, IEEE Access 12 (2024) 145400â145416. doi:10.1109/ACCESS.2024.3453034. [12] M. Fidler, Survey of deterministic and stochastic service curve models in the network calculus, IEEE Communications Surveys & Tutorials 12 (1) (2010) 59â86. doi:10.1109/SURV.2010.020110.00019. [13] Y. Jiang, Y. Liu, Stochastic Network Calculus, 1st Edition, Springer Publishing Company, Incorporated, 2008. [14] W. Jiang, Graph-based deep learning for communication net- works: A survey, Computer Communications 185 (2022) 40â54. doi:https://doi.org/10.1016/j.comcom.2021.12.015. URL https://w.sciencedirect.com/science/article/pii/ S0140366421004874 [15] Q. Zhang, K. K. W. Ng, C. Kazer, S. Yan, J. Sedoc, V. Liu, Mim- icNet: fast performance estimates for data center networks with ma- chine learning, in: Proceedings of the 2021 ACM SIGCOMM 2021 Con- ference, SIGCOMM â21, Association for Computing Machinery, New York, NY, USA, 2021, p. 287â304. doi:10.1145/3452296.3472926. URL https://doi.org/10.1145/3452296.3472926 [16] Q. Yang, X. Peng, L. Chen, L. Liu, J. Zhang, H. Xu, B. Li, G. Zhang, DeepQueueNet: towards scalable and generalized network performance estimation with packet-level visibility, in: Proceedings of the ACM SIGCOMM 2022 Conference, SIGCOMM â22, Association for Computing Machinery, New York, NY, USA, 2022, p. 441â457. doi:10.1145/3544216.3544248. URL https://doi.org/10.1145/3544216.3544248 [17] M. Ferriol-GalmĂŠs, J. Paillisse, J. SuĂĄrez-Varela, K. Rusek, S. Xiao, X. Shi, X. Cheng, P. Barlet-Ros, A. Cabellos-Aparicio, RouteNet-Fermi: Network Modeling With Graph Neural Networks, 67 IEEE/ACM Transactions on Networking 31 (6) (2023) 3080â3095. doi:10.1109/TNET.2023.3269983. [18] K. Gao, L. Chen, D. Li, V. Liu, X. Wang, R. Zhang, L. Lu, DONS: Fast and Affordable Discrete Event Network Simulation with Automatic Parallelization, in: Proceedings of the ACM SIGCOMM 2023 Con- ference, ACM SIGCOMM â23, Association for Computing Machinery, New York, NY, USA, 2023, p. 167â181. doi:10.1145/3603269.3604844. URL https://doi.org/10.1145/3603269.3604844 [19] V. Arun, M. T. Arashloo, A. Saeed, M. Alizadeh, H. Balakrishnan, Toward formally verifying congestion control behavior, in: Proceedings of the 2021 ACM SIGCOMM 2021 Conference, ACM, New York, NY, USA, 2021, p. 1â16. doi:10.1145/3452296.3472912. [20] M. T. Arashloo, R. Beckett, R. Agarwal, Formal Methods for Network Performance Analysis, in: 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), USENIX Association, Boston, MA, 2023, p. 645â661. URL https://w.usenix.org/conference/nsdi23/ presentation/tahmasbi [21] Y. Zhu, H. Eran, D. Firestone, C. Guo, M. Lipshteyn, Y. Liron, J. Pad- hye, S. Raindel, M. H. Yahia, M. Zhang, Congestion control for large- scale rdma deployments, SIGCOMM Comput. Commun. Rev. 45 (4) (2015) 523â536. doi:10.1145/2829988.2787484. URL https://doi.org/10.1145/2829988.2787484 [22] T. N. Kipf, M. Welling, Semi-supervised classification with graph con- volutional networks, arXiv preprint arXiv:1609.02907 (2016). [23] Y. Li, R. Zemel, M. Brockschmidt, D. Tarlow, Gated graph sequence neural networks, in: Proceedings of ICLRâ16, proceedings of iclrâ16 Edition, 2016. URL https://w.microsoft.com/en-us/research/publication/ gated-graph-sequence-neural-networks/ [24] F. Scarselli, M. Gori, A. C. Tsoi, M. Hagenbuchner, G. Monfardini, The graph neural network model, IEEE Transactions on Neural Networks 20 (1) (2009) 61â80. doi:10.1109/TNN.2008.2005605. 68 [25] S.Hochreiter,J.Schmidhuber,Longshort-term memory,Neural Computation 9 (8) (1997) 1735â 1780.arXiv:https://direct.mit.edu/neco/article- pdf/9/8/1735/813796/neco.1997.9.8.1735.pdf, doi:10.1162/neco.1997.9.8.1735. URL https://doi.org/10.1162/neco.1997.9.8.1735 [26] J. Gilmer, S. S. Schoenholz, P. F. Riley, O. Vinyals, G. E. Dahl, Neural message passing for quantum chemistry, in: D. Precup, Y. W. Teh (Eds.), Proceedings of the 34th International Conference on Machine Learning, Vol. 70 of Proceedings of Machine Learning Research, PMLR, 2017, p. 1263â1272. URL https://proceedings.mlr.press/v70/gilmer17a.html [27] M. Garnelo, J. Schwarz, D. Rosenbaum, F. Viola, D. J. Rezende, S. M. A. Eslami, Y. W. Teh, Neural processes (2018). arXiv:1807.01622. URL https://arxiv.org/abs/1807.01622 [28] The Network Simulator - ns-2 (7 1995). URL https://w.isi.edu/websites/nsnam/ns/ [29] G. F. Riley, T. R. Henderson, The ns-3 Network Simulator, in: Mod- eling and Tools for Network Simulation, Springer Berlin Heidelberg, Berlin, Heidelberg, 2010, p. 15â34. doi:10.1007/978-3-642-12331-3_2. URL http://link.springer.com/10.1007/978-3-642-12331-3_2 [30] J.-Y. Le Boudec, P. Thiran (Eds.), Network Calculus, Vol. 2050 of Lecture Notes in Computer Science, Springer Berlin Heidelberg, Berlin, Heidelberg, 2001. doi:10.1007/3-540-45318-0. URL http://link.springer.com/10.1007/3-540-45318-0 [31] M. Fidler, Extending the Network Calculus Pay Bursts Only Once Principle to Aggregate Scheduling, 2003, p. 19â34. doi:10.1007/3- 540-36480-3_2. URL http://link.springer.com/10.1007/3-540-36480-3_2 [32] M. Schlichtkrull, T. N. Kipf, P. Bloem, R. Van Den Berg, I. Titov, M. Welling, Modeling relational data with graph convolutional net- works, in: The semantic web: 15th international conference, ESWC 69 2018, Heraklion, Crete, Greece, June 3â7, 2018, proceedings 15, Springer, 2018, p. 593â607. [33] Resilient overlay networks (2001). URL http://nms.lcs.mit.edu/ron/ [34] M. Alizadeh, A. Greenberg, D. A. Maltz, J. Padhye, P. Patel, B. Prab- hakar, S. Sengupta, M. Sridharan, Data center tcp (dctcp), in: Pro- ceedings of the ACM SIGCOMM 2010 Conference, SIGCOMM â10, Association for Computing Machinery, New York, NY, USA, 2010, p. 63â74. doi:10.1145/1851182.1851192. URL https://doi.org/10.1145/1851182.1851192 [35] S. Bondorf, P. Nikolaus, J. B. Schmitt, Quality and Cost of Deter- ministic Network Calculus: Design and Evaluation of an Accurate and Fast Analysis, Proceedings of the ACM on Measurement and Analysis of Computing Systems 1 (1) (2017) 1â34. doi:10.1145/3084453. URL https://dl.acm.org/doi/10.1145/3084453 [36] A. Varga, OMNeT++, in: Wehrle Klaus, M. GĂźneĹ, Gross James (Eds.), Modeling and Tools for Network Simulation, Springer Berlin Heidelberg, Berlin, Heidelberg, 2010, p. 35â59. doi:10.1007/978-3- 642-12331-3_3. URL https://doi.org/10.1007/978-3-642-12331-3_3 [37] Q. He, C. Dovrolis, M. Ammar, On the predictability of large trans- fer TCP throughput, in: Proceedings of the 2005 conference on Ap- plications, technologies, architectures, and protocols for computer communications, ACM, New York, NY, USA, 2005, p. 145â156. doi:10.1145/1080091.1080110. URL https://dl.acm.org/doi/10.1145/1080091.1080110 [38] B. K. de Aquino Afonso, L. Berton, QT-Routenet: Improved GNN generalization to larger 5G networks by fine-tuning predictions from queueing theory, ITU Journal on Future and Evolving Technologies 3 (2) (2022) 134â141. doi:10.52953/FBRB3688. URL https://w.itu.int/pub/S-JNL-VOL3.ISSUE2-2022-A12 [39] M. Helm, G. Carle, Predicting Latency Quantiles using Network Calculus-assisted GNNs, in: Proceedings of the 2nd on Graph 70 Neural Networking Workshop 2023, GNNet â23, Association for Computing Machinery, New York, NY, USA, 2023, p. 13â18. doi:10.1145/3630049.3630173. URL https://doi.org/10.1145/3630049.3630173 [40] F. Y. Yan, J. Ma, G. D. Hill, D. Raghavan, R. S. Wahby, P. Levis, K. Winstein, Pantheon: the training ground for Internet congestion- control research, in: 2018 USENIX Annual Technical Conference (USENIX ATC 18), USENIX Association, Boston, MA, 2018, p. 731â 743. URL https://w.usenix.org/conference/atc18/presentation/ yan-francis [41] S. Ashok, S. Tiwari, N. Natarajan, V. N. Padmanabhan, S. Sellaman- ickam, Data-Driven Network Path Simulation with iBox, Proceedings of the ACM on Measurement and Analysis of Computing Systems 6 (1) (2022) 1â26. doi:10.1145/3508026. URL https://dl.acm.org/doi/10.1145/3508026 [42] Yu Gu, Yong Liu, D. Towsley, On integrating fluid models with packet simulation, in: IEEE INFOCOM 2004, Vol. 4, IEEE, 2004, p. 2856â 2866. doi:10.1109/INFCOM.2004.1354702. URL http://ieeexplore.ieee.org/document/1354702/ [43] A. Alomar, P. Hamadanian, A. Nasr-Esfahany, A. Agarwal, M. Al- izadeh, D. Shah, CausalSim: A Causal Framework for Unbiased Trace-Driven Simulation, in: 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), USENIX Association, Boston, MA, 2023, p. 1115â1147. URL https://w.usenix.org/conference/nsdi23/ presentation/alomar [44] J. Späth, M. Helm, B. Jaeger, G. Carle, Sim2HW: Modeling La- tency Offset Between Network Simulations and Hardware Measure- ments, in: Proceedings of the 3rd GNNet Workshop on Graph Neural Networking Workshop, ACM, New York, NY, USA, 2024, p. 20â26. doi:10.1145/3694811.3697820. URL https://dl.acm.org/doi/10.1145/3694811.3697820 71 [45] M. Guizani, A. Rayes, B. Khan, A. Al-Fuqaha, Network Modeling and Simulation, Wiley, 2010. doi:10.1002/9780470515211. URL https://onlinelibrary.wiley.com/doi/book/10.1002/ 9780470515211 [46] S. Keshav, REAL: A Network Simulator, Tech. Rep. UCB/CSD-88-472 (12 1988). URL http://w2.eecs.berkeley.edu/Pubs/TechRpts/1988/ 5316.html [47] X. Chang, Network simulations with OPNET, in: Proceedings of the 31st conference on Winter simulation Simulationâa bridge to the fu- ture - WSC â99, ACM Press, New York, New York, USA, 1999, p. 307â314. doi:10.1145/324138.324232. [48] BĂźltmann Daniel, M. MĂźhleisen, Max Sebastian, Open WNS, in: Wehrle Klaus, M. GĂźneĹ, Gross James (Eds.), Modeling and Tools for Network Simulation, Springer Berlin Heidelberg, Berlin, Heidelberg, 2010, p. 69â81. doi:10.1007/978-3-642-12331-3_5. URL https://doi.org/10.1007/978-3-642-12331-3_5 [49] J. Sommer, J. Scharf, IKR Simulation Library, in: Wehrle Klaus, M. GĂźneĹ, Gross James (Eds.), Modeling and Tools for Network Simu- lation, Springer Berlin Heidelberg, Berlin, Heidelberg, 2010, p. 61â68. doi:10.1007/978-3-642-12331-3_4. URL https://doi.org/10.1007/978-3-642-12331-3_4 [50] G. Casale, G. Serazzi, Quantitative system evaluation with Java mod- eling tools, in: Proceedings of the 2nd ACM/SPEC International Con- ference on Performance engineering, ACM, New York, NY, USA, 2011, p. 449â454. doi:10.1145/1958746.1958813. URL https://dl.acm.org/doi/10.1145/1958746.1958813 [51] N. Binkert, B. Beckmann, G. Black, S. K. Reinhardt, A. Saidi, A. Basu, J. Hestness, D. R. Hower, T. Krishna, S. Sardashti, R. Sen, K. Sewell, M. Shoaib, N. Vaish, M. D. Hill, D. A. Wood, The gem5 simula- tor, ACM SIGARCH Computer Architecture News 39 (2) (2011) 1â7. doi:10.1145/2024716.2024718. 72 [52] M. Alian, D. Kim, N. Sung Kim, pd-gem5: Simulation Infrastructure for Parallel/Distributed Computer Systems, IEEE Computer Architec- ture Letters 15 (1) (2016) 41â44. doi:10.1109/LCA.2015.2438295. URL http://ieeexplore.ieee.org/document/7114236/ [53] H. Li, J. Li, A. Kaufmann, SimBricks: end-to-end network system evaluation with modular simulation, in: Proceedings of the ACM SIG- COMM 2022 Conference, ACM, New York, NY, USA, 2022, p. 380â 396. doi:10.1145/3544216.3544253. URL https://dl.acm.org/doi/10.1145/3544216.3544253 [54] H. Li, P. Balasubramanian, M. Meiers, J. Li, A. Kaufmann, Split- Sim: Large-Scale Simulations for Evaluating Network Systems Re- search (2024). URL https://arxiv.org/abs/2402.05312 [55] S. Bai, H. Zheng, C. Tian, X. Wang, C. Liu, X. Jin, F. Xiao, Q. Xiang, W. Dou, G. Chen, Unison: A Parallel-Efficient and User-Transparent Network Simulation Kernel, in: Proceedings of the Nineteenth Euro- pean Conference on Computer Systems, ACM, New York, NY, USA, 2024, p. 115â131. doi:10.1145/3627703.3629574. URL https://dl.acm.org/doi/10.1145/3627703.3629574 [56] S. Khashab, H. Sezhiyan, R. Abboud, A. Normatov, S. Kaestle, E. Bar- Ilan, M. Nassar, O. Shabtai, W. Bai, M. Kadosh, J. Xing, M. Silber- stein, T. E. Ng, A. Chen, Nsx: Large-scale network simulation on an ai server, in: Proceedings of the 2nd Workshop on Networks for AI Com- puting, NAIC â25, Association for Computing Machinery, New York, NY, USA, 2025, p. 19â25. doi:10.1145/3748273.3749199. URL https://doi.org/10.1145/3748273.3749199 [57] K. Zhao, P. Goyal, M. Alizadeh, T. E. Anderson, Scalable Tail Latency Estimation for Data Center Networks (2022). URL https://arxiv.org/abs/2205.01234 [58] C. GĂźemes-Palau, M. Ferriol-GalmĂŠs, J. Paillisse-Vilanova, A. LĂłpez- BrescĂł, P. Barlet-Ros, A. Cabellos-Aparicio, RouteNet-Gauss: Hardware-Enhanced Network Modeling with Machine Learning (1 2025). 73 [59] S. Floyd, V. Paxson, Difficulties in simulating the Internet, IEEE/ACM Transactions on Networking 9 (4) (2001) 392â403. doi:10.1109/90.944338. [60] V. Paxson, S. Floyd, Why we donât know how to simulate the in- ternet, in: Proceedings of the 29th Conference on Winter Simula- tion, WSC â97, IEEE Computer Society, USA, 1997, p. 1037â1044. doi:10.1145/268437.268737. URL https://doi.org/10.1145/268437.268737 [61] R. Fujimoto, Parallel and distributed simulation systems, in: Proceed- ing of the 2001 Winter Simulation Conference (Cat. No.01CH37304), IEEE, 2001, p. 147â157. doi:10.1109/WSC.2001.977259. URL http://ieeexplore.ieee.org/document/977259/ [62] G. Kunz, Parallel Discrete Event Simulation, in: Wehrle Klaus, M. GĂźneĹ, Gross James (Eds.), Modeling and Tools for Network Sim- ulation, Springer Berlin Heidelberg, Berlin, Heidelberg, 2010, p. 121â 131. doi:10.1007/978-3-642-12331-3_8. URL https://doi.org/10.1007/978-3-642-12331-3_8 [63] S. Jafer, Q. Liu, G. Wainer, Synchronization methods in parallel and distributed discrete-event simulation, Sim- ulation Modelling Practice and Theory 30 (2013) 54â73. doi:https://doi.org/10.1016/j.simpat.2012.08.003. URL https://w.sciencedirect.com/science/article/pii/ S1569190X12001244 [64] H. Kobayashi, A. Konheim, Queueing Models for Computer Communi- cations System Analysis, IEEE Transactions on Communications 25 (1) (1977) 2â29. doi:10.1109/TCOM.1977.1093702. URL http://ieeexplore.ieee.org/document/1093702/ [65] W. chung Poon, K. tung Lo, A refined version of m/g/â processes for modelling vbr video traffic, Computer Communications 24 (2001) 1105â1114. doi:10.1016/S0140-3664(00)00325-X. [66] F. Fiorini, M. Cococcioni, M. Pagano, Quantitative delay analysis of gi/g/1 queues with heavy-tailed traffic by means of alpha the- ory, Computer Networks 269 (2025) 111394, vERY math have. Ba- sically, propases a methodology based on nonstandard analysis to 74 derive an approximation of a GI/G/1 queue. Can be used for ob- tainin estimated mean delay, but also upper and lower bounds. doi:10.1016/j.comnet.2025.111394. [67] M. Garetto, R. Lo Cigno, M. Meo, M. Ajmone Marsan, A detailed and accurate closed queueing network model of many interacting TCP flows, in: Proceedings IEEE INFOCOM 2001. Conference on Computer Communications. Twentieth Annual Joint Conference of the IEEE Computer and Communications Society (Cat. No.01CH37213), Vol. 3, IEEE, 2001, p. 1706â1715. doi:10.1109/INFCOM.2001.916668. URL http://ieeexplore.ieee.org/document/916668/ [68] M. Garetto, Renato Lo Cigno, M. Meo, M. Marsan, Closed queueing network models of interacting long-lived TCP flows, IEEE/ACM Transactions on Networking 12 (2) (2004) 300â311. doi:10.1109/TNET.2004.826297. URL https://ieeexplore.ieee.org/document/1288134/ [69] M. Yu, M. Zhou, A Performance Modeling Scheme for Mul- tistage Switch Networks With Phase-Type and Bursty Traffic, IEEE/ACM Transactions on Networking 18 (4) (2010) 1091â1104. doi:10.1109/TNET.2009.2036437. URL http://ieeexplore.ieee.org/document/5352328/ [70] T. Bonald, Comparison of TCP Reno and TCP Vegas: effi- ciency and fairness, Performance Evaluation 36-37 (1999) 307â332. doi:10.1016/S0166-5316(99)00037-1. [71] F. Baccelli, D. Hong, AIMD, fairness and fractal scaling of TCP traffic, in: Proceedings.Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies, Vol. 1, IEEE, New York, 2002, p. 229â238. doi:10.1109/INFCOM.2002.1019264. URL http://ieeexplore.ieee.org/document/1019264/ [72] S. Bohacek, A stochastic model of TCP and fair video trans- mission, in: IEEE INFOCOM 2003. Twenty-second Annual Joint Conference of the IEEE Computer and Communications Soci- eties (IEEE Cat. No.03CH37428), IEEE, 2003, p. 1134â1144. doi:10.1109/INFCOM.2003.1208950. URL https://ieeexplore.ieee.org/document/1208950/ 75 [73] V. Misra, W.-B. Gong, D. Towsley, Fluid-based analysis of a network of AQM routers supporting TCP flows with an application to RED, in: Proceedings of the conference on Applications, Technologies, Architec- tures, and Protocols for Computer Communication, ACM, New York, NY, USA, 2000, p. 151â160. doi:10.1145/347059.347421. URL https://dl.acm.org/doi/10.1145/347059.347421 [74] Y. Liu, F. Lo Presti, V. Misra, D. Towsley, Y. Gu, Fluid models and solutions for large-scale IP networks, in: Proceedings of the 2003 ACM SIGMETRICS international conference on Measurement and modeling of computer systems, ACM, New York, NY, USA, 2003, p. 91â101. doi:10.1145/781027.781039. URL https://dl.acm.org/doi/10.1145/781027.781039 [75] F. Baccelli, D. Hong, Flow level simulation of large IP net- works, in: IEEE INFOCOM 2003. Twenty-second Annual Joint Conference of the IEEE Computer and Communications Societies (IEEE Cat. No.03CH37428), Vol. 3, IEEE, 2003, p. 1911â1921. doi:10.1109/INFCOM.2003.1209213. URL http://ieeexplore.ieee.org/document/1209213/ [76] S. Bohacek, J. P. Hespanha, J. Lee, K. Obraczka, A hybrid sys- tems modeling framework for fast and accurate simulation of data communication networks, in: Proceedings of the 2003 ACM SIG- METRICS international conference on Measurement and modeling of computer systems, ACM, New York, NY, USA, 2003, p. 58â69. doi:10.1145/781027.781036. URL https://dl.acm.org/doi/10.1145/781027.781036 [77] J. Lee, S. Bohacek, J. P. Hespanha, K. Obraczka, Modeling Commu- nication Networks With Hybrid Systems, IEEE/ACM Transactions on Networking 15 (3) (2007) 630â643. doi:10.1109/TNET.2007.893090. URL http://ieeexplore.ieee.org/document/4237147/ [78] M. Marsan, M. Garetto, P. Giaccone, E. Leonardi, E. Schiattarella, A. Tarello, Using partial differential equations to model TCP mice and elephants in large IP networks, in: IEEE INFOCOM 2004, Vol. 4, IEEE, 2004, p. 2821â2832. doi:10.1109/INFCOM.2004.1354699. URL http://ieeexplore.ieee.org/document/1354699/ 76 [79] F. Baccelli, G. Carofiglio, M. Piancino, Stochastic Analysis of Scal- able TCP, in: IEEE INFOCOM 2009, IEEE, 2009, p. 19â27. doi:10.1109/INFCOM.2009.5061902. URL https://ieeexplore.ieee.org/document/5061902/ [80] G. Carofiglio, L. Muscariello, On the Impact of TCP and Per-Flow Scheduling on Internet Performance, in: 2010 Proceedings IEEE IN- FOCOM, IEEE, 2010, p. 1â9. doi:10.1109/INFCOM.2010.5461973. URL http://ieeexplore.ieee.org/document/5461973/ [81] T. CzachĂłrski, Queueing Models for Performance Evaluation of Computer NetworksâTransient State Analysis, 2015, p. 51â80. doi:10.1007/978-3-319-12148-2_4. URL https://link.springer.com/10.1007/978-3-319-12148-2_4 [82] E. Knightly, Hui Zhang, D-BIND: an accurate traffic model for pro- viding QoS guarantees to VBR traffic, IEEE/ACM Transactions on Networking 5 (2) (1997) 219â231. doi:10.1109/90.588085. URL http://ieeexplore.ieee.org/document/588085/ [83] R. Agrawal, R. Cruz, C. Okino, R. Rajan, Performance bounds for flow control protocols, IEEE/ACM Transactions on Networking 7 (3) (1999) 310â323. doi:10.1109/90.779197. [84] K. Lampka, S. Bondorf, J. Schmitt, Achieving Efficiency without Sac- rificing Model Accuracy: Network Calculus on Compact Domains, in: 2016 IEEE 24th International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems (MAS- COTS), IEEE, 2016, p. 313â318. doi:10.1109/MASCOTS.2016.9. URL http://ieeexplore.ieee.org/document/7774596/ [85] J. B. Schmitt, F. A. Zdarsky, M. Fidler, Delay Bounds under Arbitrary Multiplexing: When Network Calculus Leaves You in the Lurch..., in: IEEE INFOCOM 2008 - The 27th Conference on Computer Communi- cations, IEEE, 2008, p. 1669â1677. doi:10.1109/INFOCOM.2008.228. URL http://ieeexplore.ieee.org/document/4509823/ [86] A. Bouillard, E. Thierry, Tight performance bounds in the worst-case analysis of feed-forward networks, Discrete Event Dynamic Systems 77 26 (3) (2016) 383â411. doi:10.1007/s10626-015-0213-2. URL http://link.springer.com/10.1007/s10626-015-0213-2 [87] A. Kiefer, N. Gollan, J. B. Schmitt, Searching for Tight Performance Bounds in Feed-Forward Networks, in: B. MĂźller-Clostermann, K. Ech- tle, Rathgeb Erwin P (Eds.), Measurement, Modelling, and Evalua- tion of Computing Systems and Dependability and Fault Tolerance, Springer Berlin Heidelberg, Berlin, Heidelberg, 2010, p. 227â241. doi:10.1007/978-3-642-12104-3_18. URL http://link.springer.com/10.1007/978-3-642-12104-3_18 [88] Cheng-Shang Chang, Stability, queue length, and delay of deterministic and stochastic queueing networks, IEEE Transactions on Automatic Control 39 (5) (1994) 913â931. doi:10.1109/9.284868. [89] Y. Jiang, A basic stochastic network calculus, ACM SIG- COMM Computer Communication Review 36 (4) (2006) 123â134. doi:10.1145/1151659.1159929. [90] K. Angrishi, An end-to-end stochastic network calculus with ef- fective bandwidth and effective capacity, Computer Networks 57 (2013) 78â84, stochastic NC, makes bound tighter based on es- timating the effective bandwidth. However, no evaluation added. doi:10.1016/j.comnet.2012.09.003. [91] T. Lakshman, U. Madhow, The performance of TCP/IP for networks with high bandwidth-delay products and random loss, IEEE/ACM Transactions on Networking 5 (3) (1997) 336â350. doi:10.1109/90.611099. URL http://ieeexplore.ieee.org/document/611099/ [92] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, Modeling TCP Reno performance: a simple model and its empirical validation, IEEE/ACM Transactions on Networking 8 (2) (2000) 133â145. doi:10.1109/90.842137. URL http://ieeexplore.ieee.org/document/842137/ [93] R. Mazumdar, L. Mason, C. Douligeris, Fairness in network optimal flow control: optimality of product forms, IEEE Transactions on Com- munications 39 (5) (1991) 775â782. doi:10.1109/26.87140. 78 [94] F. P. Kelly, A. K. Maulloo, D. K. H. Tan, Rate control for commu- nication networks: shadow prices, proportional fairness and stability, Journal of the Operational Research Society 49 (3) (1998) 237â252. doi:10.1057/palgrave.jors.2600523. URL https://w.tandfonline.com/doi/full/10.1057/ palgrave.jors.2600523 [95] W. WHITT, Approximations for the gi/g/m queue, Pro- duction and Operations Management 2 (2) (1993) 114â 161.arXiv:https://doi.org/10.1111/j.1937-5956.1993.tb00094.x, doi:10.1111/j.1937-5956.1993.tb00094.x. URL https://doi.org/10.1111/j.1937-5956.1993.tb00094.x [96] K. Chandy, The analysis and solutions for general queueing networks, in: Proceedings of the Sixth Anual Princeton Conference on Informa- tion Sciences and Systems, 1972, p. 224â228. [97] M. Reiser, S. S. Lavenberg, Mean-value analysis of closed mul- tichain queuing networks, J. ACM 27 (2) (1980) 313â322. doi:10.1145/322186.322195. URL https://doi.org/10.1145/322186.322195 [98] K. M. Chandy, C. H. Sauer, Computational algorithms for product form queueing networks, Communications of the ACM 23 (10) (1980) 573â583. doi:10.1145/359015.359020. URL https://dl.acm.org/doi/10.1145/359015.359020 [99] A. Charny, J.-Y. L. Boudec, Delay Bounds in a Network with Aggregate Scheduling, in: Crowcroft Jon, J. Roberts, Smirnov Mikhail I (Eds.), Quality of Future Internet Services, Springer Berlin Heidelberg, Berlin, Heidelberg, 2000, p. 1â13. [100] D. Starobinski, M. Karpovsky, L. Zakrevski, Application of network calculus to general topologies using turn-prohibition, IEEE/ACM Transactions on Networking 11 (3) (2003) 411â421. doi:10.1109/TNET.2003.813040. URL http://ieeexplore.ieee.org/document/1208302/ [101] M. Fidler, A. Rizk, A Guide to the Stochastic Network Calculus, IEEE Communications Surveys & Tutorials 17 (1) (2015) 92â105. 79 doi:10.1109/COMST.2014.2337060. URL https://ieeexplore.ieee.org/document/6868978/ [102] F. Ciucu, J. Schmitt, Perspectives on network calculus, ACM SIG- COMM Computer Communication Review 42 (4) (2012) 311â322. doi:10.1145/2377677.2377747. URL https://dl.acm.org/doi/10.1145/2377677.2377747 [103] M. Mirza, J. Sommers, P. Barford, X. Zhu, A Machine Learning Ap- proach to TCP Throughput Prediction, IEEE/ACM Transactions on Networking 18 (4) (2010) 1026â1039. doi:10.1109/TNET.2009.2037812. URL https://ieeexplore.ieee.org/document/5378489 [104] M. B. Tariq, K. Bhandankar, V. Valancius, A. Zeitoun, N. Feam- ster, M. Ammar, Answering âWhat-Ifâ Deployment and Configu- ration Questions With WISE: Techniques and Deployment Experi- ence, IEEE/ACM Transactions on Networking 21 (1) (2013) 1â13. doi:10.1109/TNET.2012.2230448. [105] M. Helm, F. Wiedner, G. Carle, Flow-level Tail Latency Estimation and Verification based on Extreme Value Theory, in: 2022 18th In- ternational Conference on Network and Service Management (CNSM), IEEE, 2022, p. 359â363. doi:10.23919/CNSM55787.2022.9964525. URL https://ieeexplore.ieee.org/document/9964525/ [106] D. Monaco, A. Sacco, D. Spina, F. Strada, A. Bottino, T. Cerquitelli, G. Marchetto, Real-time latency prediction for cloud gaming applications, Computer Networks 264 (2025) 111235. doi:10.1016/j.comnet.2025.111235. URL https://linkinghub.elsevier.com/retrieve/pii/ S1389128625002038 [107] A. Mestres, E. AlarcĂłn, Y. Ji, A. Cabellos-Aparicio, Understanding the Modeling of Computer Network Delays using Neural Networks, in: Proceedings of the 2018 Workshop on Big Data Analytics and Machine Learning for Data Communication Networks, ACM, New York, NY, USA, 2018, p. 46â52. doi:10.1145/3229607.3229613. URL https://dl.acm.org/doi/10.1145/3229607.3229613 80 [108] F. Krasniqi, J. Elias, J. Leguay, A. E. C. Redondi, End-to-end Delay Prediction Based on Traffic Matrix Sampling, in: IEEE INFOCOM 2020 - IEEE Conference on Computer Communica- tions Workshops (INFOCOM WKSHPS), IEEE, 2020, p. 774â779. doi:10.1109/INFOCOMWKSHPS50562.2020.9162765. URL https://ieeexplore.ieee.org/document/9162765/ [109] K. Rusek, J. SuĂĄrez-Varela, A. Mestres, P. Barlet-Ros, A. Cabellos- Aparicio, Unveiling the potential of Graph Neural Networks for network modeling and optimization in SDN, in: Proceedings of the 2019 ACM Symposium on SDN Research, ACM, New York, NY, USA, 2019, p. 140â151. doi:10.1145/3314148.3314357. URL https://dl.acm.org/doi/10.1145/3314148.3314357 [110] J. SuĂĄrez-Varela, S. Carol-Bosch, K. Rusek, P. Almasan, M. Arias, P. Barlet-Ros, A. Cabellos-Aparicio, Challenging the generaliza- tion capabilities of Graph Neural Networks for network model- ing, in: Proceedings of the ACM SIGCOMM 2019 Conference Posters and Demos, ACM, New York, NY, USA, 2019, p. 114â115. doi:10.1145/3342280.3342327. URL https://dl.acm.org/doi/10.1145/3342280.3342327 [111] K. Rusek, J. SuĂĄrez-Varela, P. Almasan, P. Barlet-Ros, A. Cabellos- Aparicio, RouteNet: Leveraging Graph Neural Networks for Net- work Modeling and Optimization in SDN, IEEE Journal on Selected Areas in Communications 38 (10) (2020) 2260â2270. doi:10.1109/JSAC.2020.3000405. [112] A. Badia-Sampera, J. SuĂĄrez-Varela, P. Almasan, K. Rusek, P. Barlet- Ros, A. Cabellos-Aparicio, Towards more realistic network mod- els based on Graph Neural Networks, in: Proceedings of the 15th International Conference on emerging Networking EXperiments and Technologies, ACM, New York, NY, USA, 2019, p. 14â16. doi:10.1145/3360468.3366773. URL https://dl.acm.org/doi/10.1145/3360468.3366773 [113] M. Ferriol-GalmĂŠs, K. Rusek, J. SuĂĄrez-Varela, S. Xiao, X. Shi, X. Cheng, B. Wu, P. Barlet-Ros, A. Cabellos-Aparicio, 81 RouteNet-Erlang: A Graph Neural Network for Network Per- formance Evaluation, in: IEEE INFOCOM 2022 - IEEE Con- ference on Computer Communications, 2022, p. 2018â2027. doi:10.1109/INFOCOM48880.2022.9796944. [114] B. K. Dhamala, B. R. Dawadi, P. Manzoni, B. K. Acharya, Perfor- mance Evaluation of Graph Neural Network-Based RouteNet Model with Attention Mechanism, Future Internet 16 (4) (2024) 116. doi:10.3390/fi16040116. [115] ClĂĄudio Modesto, Rebecca Aben-Athar, Andrey Silva, Silvia Lins, Glauco Gon alves, Aldebaro Klautau, Delay estimation based on mul- tiple stage message passing with attention mechanism using a real net- work communication dataset, ITU Journal on Future and Evolving Technologies 5 (4) (2024) 465â477. doi:10.52953/RBNE4256. URL https://w.itu.int/pub/S-JNL-VOL5.ISSUE4-2024-A35 [116] Kaan Aykurt, Maximilian Stephan, Serkut Ayvasik, Johannes Zerwas, Wolfgang Kellerer, Digital twin opportunities with leveraging graph neural networks on real network data, ITU Journal on Future and Evolving Technologies 5 (4) (2024) 458â464. doi:10.52953/ZOEM2142. URL https://w.itu.int/pub/S-JNL-VOL5.ISSUE4-2024-A34 [117] C. GĂźemes-Palau, M. Ferriol-GalmĂŠs, J. Paillisse-Vilanova, A. LĂłpez- BrescĂł, P. Barlet-Ros, A. Cabellos-Aparicio, Wavelet-Enhanced Graph Neural Networks: Towards Non-Parametric Network Traffic Model- ing, in: Proceedings of the 3rd GNNet Workshop on Graph Neural Networking Workshop, ACM, New York, NY, USA, 2024, p. 14â19. doi:10.1145/3694811.3697823. [118] F. Geyer, DeepComNet: Performance evaluation of network topologies using graph-based deep learning, Performance Evaluation 130 (2019) 1â16. doi:10.1016/j.peva.2018.12.003. URL https://w.sciencedirect.com/science/article/abs/ pii/S0166531618300944 [119] B. Jaeger, M. Helm, L. Schwegmann, G. Carle, Modeling TCP perfor- mance using graph neural networks, in: Proceedings of the 1st Interna- tional Workshop on Graph Neural Networking, ACM, New York, NY, USA, 2022, p. 18â23. doi:10.1145/3565473.3569190. 82 [120] T. Suzuki, Y. Yasuda, R. Nakamura, H. Ohsaki, On Estimat- ing Communication Delays using Graph Convolutional Networks with Semi-Supervised Learning, in: 2020 International Conference on Information Networking (ICOIN), IEEE, 2020, p. 481â486. doi:10.1109/ICOIN48656.2020.9016603. URL https://ieeexplore.ieee.org/document/9016603 [121] J. Liu, F. Tang, L. Chen, X. Li, J. Yu, Y. Zhu, Y. Yu, Y. Yang, EAGLE: Heterogeneous GNN-based Network Perfor- mance Analysis, in: 2023 IEEE/ACM 31st International Sym- posium on Quality of Service (IWQoS), IEEE, 2023, p. 1â10. doi:10.1109/IWQoS57198.2023.10188804. URL https://ieeexplore.ieee.org/abstract/document/ 10188804 [122] S. Huang, Y. Wei, L. Peng, M. Wang, L. Hui, P. Liu, Z. Du, Z. Liu, Y. Cui, xNet: Modeling Network Performance With Graph Neural Networks, IEEE/ACM Transactions on Networking 32 (2) (2024) 1753â 1767. doi:10.1109/TNET.2023.3329357. [123] B. Li, G. Verma, T. Efimov, A. Kumar, S. Segarra, GLANCE: Graph- based Learnable Digital Twin for Communication Networks (2024). URL https://arxiv.org/abs/2408.09040 [124] H. Du, M. Li, FlowSeer: A Novel Framework for Gen- eralized Network Performance Estimation at Flow Level, in: 2024 27th International Conference on Computer Supported Co- operative Work in Design (CSCWD), 2024, p. 2834â2839. doi:10.1109/CSCWD61410.2024.10580262. [125] C. Li, A. A. Zabreyko, A. Nasr-Esfahany, K. Zhao, P. Goyal, M. Al- izadeh, T. Anderson, m4: A Learned Flow-level Network Simulator (3 2025). URL http://arxiv.org/abs/2503.01770 [126] W. L. Hamilton, R. Ying, J. Leskovec, Inductive representation learn- ing on large graphs, in: Proceedings of the 31st International Con- ference on Neural Information Processing Systems, NIPSâ17, Curran Associates Inc., Red Hook, NY, USA, 2017, p. 1025â1035. 83 [127] K. Cho, B. van Merrienboer, C. Gulcehre, D. Bahdanau, F. Bougares, H. Schwenk, Y. Bengio, Learning phrase representations using rnn encoder-decoder for statistical machine translation (2014). arXiv:1406.1078. URL https://arxiv.org/abs/1406.1078 [128] M. Wang, Y. Cui, S. Xiao, X. Wang, D. Yang, K. Chen, J. Zhu, Neural Network Meets DCN: Traffic-driven Topology Adaptation with Deep Learning, Proceedings of the ACM on Measurement and Analysis of Computing Systems 2 (2) (2018) 1â25. doi:10.1145/3224421. URL https://dl.acm.org/doi/10.1145/3224421 [129] S. Xiao, D. He, Z. Gong, Deep-Q: Traffic-driven QoS Inference using Deep Generative Network, in: Proceedings of the 2018 Workshop on Network Meets AI & ML - NetAIâ18, ACM Press, New York, New York, USA, 2018, p. 67â73. doi:10.1145/3229543.3229549. URL http://dl.acm.org/citation.cfm?doid=3229543.3229549 [130] D. P. Kingma, M. Welling, Auto-encoding variational bayes (2022). arXiv:1312.6114. URL https://arxiv.org/abs/1312.6114 [131] A. DietmĂźller, S. Ray, R. Jacob, L. Vanbever, A new hope for network model generalization, in: Proceedings of the 21st ACM Workshop on Hot Topics in Networks, HotNets â22, Association for Computing Machinery, New York, NY, USA, 2022, p. 152â159. doi:10.1145/3563766.3564104. URL https://doi.org/10.1145/3563766.3564104 [132] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. Kaiser, I. Polosukhin, Attention is all you need (2023). arXiv:1706.03762. URL https://arxiv.org/abs/1706.03762 [133] K. Hattori, T. Korikawa, C. Takasaki, Meta Learner-Based Trans- fer Learning: Bridging Simulation and Actual Router Metrics, in: 2024 IEEE 25th International Conference on High Perfor- mance Switching and Routing (HPSR), IEEE, 2024, p. 203â208. doi:10.1109/HPSR62440.2024.10635943. URL https://ieeexplore.ieee.org/document/10635943/ 84 [134] K. Hattori, T. Korikawa, C. Takasaki, Meta Learner-Based Transfer Learning: Bridging Simulation and Actual Router Metrics, IEEE Ac- cess 13 (2025) 76085â76099. doi:10.1109/ACCESS.2025.3564954. [135] M. Happ, J. L. Du, M. Herlich, C. Maier, P. Dorfinger, J. SuĂĄrez- Varela, Exploring the Limitations of Current Graph Neural Net- works for Network Modeling, in: NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, 2022, p. 1â8. doi:10.1109/NOMS54207.2022.9789708. URL https://ieeexplore.ieee.org/document/9789708 [136] P. VeliÄkoviÄ, G. Cucurull, A. Casanova, A. Romero, P. Liò, Y. Bengio, Graph attention networks (2018). arXiv:1710.10903. URL https://arxiv.org/abs/1710.10903 [137] R. Netravali, A. Sivaraman, S. Das, A. Goyal, K. Winstein, J. Mickens, H. Balakrishnan, Mahimahi: Accurate Record-and-Replay for HTTP, in: 2015 USENIX Annual Technical Conference (USENIX ATC 15), USENIX Association, Santa Clara, CA, 2015, p. 417â429. URL https://w.usenix.org/conference/atc15/technical- session/presentation/netravali [138] J. Zhang, K. Gao, Y. R. Yang, J. Bi, Prophet: Toward Fast, Error- Tolerant Model-Based Throughput Prediction for Reactive Flows in DC Networks, IEEE/ACM Transactions on Networking 28 (6) (2020) 2475â2488. doi:10.1109/TNET.2020.3016838. URL https://ieeexplore.ieee.org/document/9178502/ [139] F. Geyer, S. Bondorf, DeepTMA: Predicting Effective Contention Mod- els for Network Calculus using Graph Neural Networks, in: IEEE INFOCOM 2019 - IEEE Conference on Computer Communications, IEEE, 2019, p. 1009â1017. doi:10.1109/INFOCOM.2019.8737496. URL https://ieeexplore.ieee.org/document/8737496/ [140] F. Geyer, S. Bondorf, On the Robustness of Deep Learning-predicted Contention Models for Network Calculus, in: 2020 IEEE Symposium on Computers and Communications (ISCC), IEEE, 2020, p. 1â7. doi:10.1109/ISCC50000.2020.9219693. URL https://ieeexplore.ieee.org/document/9219693/ 85 [141] M. Farreras, J. PaillissĂŠ, L. FĂ brega, P. VilĂ , GNNetSlice: A GNN-based performance model to support network slicing in B5G networks, Computer Communications 232 (2025) 108044. doi:10.1016/j.comcom.2025.108044. [142] R. Srikant, The Mathematics of Internet Congestion Control, 2004. doi:10.1007/978-0-8176-8216-3. [143] K. Hattori, T. Korikawa, C. Takasaki, Queue-informed neural network model for estimating queuing delay in pon-based aggre- gation networks, in: 2025 IEEE 11th International Conference on Network Softwarization (NetSoft), IEEE, 2025, p. 199â203. doi:10.1109/NetSoft64993.2025.11080627. URL https://ieeexplore.ieee.org/document/11080627/ [144] C. Li, A. Nasr-Esfahany, K. Zhao, K. Noorbakhsh, P. Goyal, M. Al- izadeh, T. E. Anderson, m3: Accurate Flow-Level Performance Es- timation using Machine Learning, in: Proceedings of the ACM SIGCOMM 2024 Conference, ACM SIGCOMM â24, Association for Computing Machinery, New York, NY, USA, 2024, p. 813â827. doi:10.1145/3651890.3672243. URL https://doi.org/10.1145/3651890.3672243 [145] P. Namyar, B. Arzani, S. Kandula, S. Segarra, D. Crankshaw, U. Kr- ishnaswamy, R. Govindan, H. Raj, Solving Max-Min fair resource allocations quickly on large graphs, in: 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), 2024, p. 1937â1958. [146] Inference code for llama models. URL https://github.com/facebookresearch/llama/blob/main/ llama/model.py [147] V. Paxson, S. Floyd, Why we donât know how to simulate the Internet, in: Proceedings of the 29th conference on Winter simulation - WSC â97, ACM Press, New York, New York, USA, 1997, p. 1037â1044. doi:10.1145/268437.268737. [148] S. Floyd, E. Kohler, Internet research needs better models, ACM SIGCOMM Computer Communication Review 33 (1) (2003) 29â34. doi:10.1145/774763.774767. 86 [149] Simple explanation of the no-free-lunch theorem and its implications, Journal of optimization theory and applications 115 (2002) 549â570. [150] C. E. Leiserson, Fat-trees: Universal networks for hardware-efficient supercomputing, IEEE Transactions on Computers C-34 (10) (1985) 892â901. doi:10.1109/TC.1985.6312192. [151] C. GĂźemes-Palau, M. Ferriol-GalmĂŠs, J. Paillisse-Vilanova, A. LĂłpez- BrescĂł, P. Barlet-Ros, A. Cabellos-Aparicio, Bridging the gap between simulated and real network data using transfer learning, arXiv preprint arXiv:2510.00956 (2025). 87