A Reproducible Monte Carlo Framework for Evaluating Cost–Latency Trade-Offs in Cloud Continuum

Abstract

Parallel, data-intensive applications are now commonly executed on infrastructures that combine Cloud, Fog, and Edge resources. In these environments, execution takes place on devices with markedly different computational power and over networks whose latency and bandwidth can fluctuate over time. Under these conditions, overall performance is influenced not only by processing speed but also by communication delays arising from data dependencies between tasks. This leads to a basic issue: whether scheduling strategies developed under computation-focused assumptions continue to perform well once communication costs are made explicit. This work examines the behavior of simple and widely adopted scheduling heuristics when network effects are modeled directly within the system. No new scheduling algorithms are introduced. Instead, the analysis focuses on how execution time and monetary cost change for deterministic parallel workloads deployed on hierarchical Cloud–Edge infrastructures exposed to stochastic latency and bandwidth variations. For this purpose, we introduce CLOWNSim, a lightweight discrete-event simulation framework that supports large-scale Monte Carlo experiments on fixed task graphs, allowing infrastructural and scheduling effects to be examined independently of workload variability. The experimental analysis covers fully centralized Cloud deployments, intermediate Fog configurations, and resource-constrained IoT scenarios. Scheduling policies based on computational speed, execution cost, or random device selection are evaluated across these settings. In Cloud and Fog environments, communication latency and data transfers represent a substantial portion of the overall makespan, weakening the impact of scheduling decisions driven primarily by computation. In IoT scenarios, limited processing capacity becomes the main limiting factor, while communication overhead remains present but less influential in comparison. The results indicate that performance trends across the Cloud–Edge continuum cannot be attributed to scheduler choice alone. Execution behavior arises from the combined effects of workload structure, placement decisions, and network properties, with different elements becoming dominant depending on the deployment context. The proposed simulation framework offers a practical way to study these interactions and to assess cost–performance trade-offs under communication conditions that reflect realistic operating environments.

1. Introduction

Data-intensive and latency-sensitive applications are increasingly executed on heterogeneous infrastructures that integrate Cloud data centers, Fog nodes, and IoT (Edge) devices (in this work, the term IoT placement is used to denote the most resource-constrained layer of the Cloud–Edge continuum, corresponding to Edge devices). This evolution toward the Cloud–Edge continuum is motivated by the need to reduce latency and alleviate network congestion by moving computation closer to data sources. At the same time, it introduces additional complexity in performance analysis: execution no longer occurs on a single, uniform platform, but is distributed across devices with distinct computational characteristics and over networks affected by non-negligible and time-varying communication delays.

Within such settings, execution time results from the combined influence of several factors. Computational speed, network latency, available bandwidth, data dependencies, and task placement decisions all contribute to observed performance, often producing effects that are difficult to anticipate. Scheduling strategies developed under assumptions of negligible communication cost may therefore behave differently once communication delays and repeated data transfers are explicitly modeled. Analytical approaches struggle to capture these interactions at scale, while detailed system simulators typically require substantial modeling effort, limiting their applicability to large comparative studies.

This work addresses these challenges by analyzing execution behavior at an intermediate level of abstraction. The goal is not to introduce new scheduling algorithms, but to examine how simple and widely adopted scheduling heuristics behave when network effects are incorporated as integral system components. The analysis emphasizes regime behavior, investigating how the relative impact of computation, communication, and placement decisions evolves as workloads transition from centralized Cloud environments to Fog deployments and resource-constrained IoT settings.

To enable this study, we introduce CLOWNSim (CLOud Workloads Naive Simulator), a lightweight discrete-event simulation framework designed to support reproducible Monte Carlo experimentation on fixed task graphs. The simulator deliberately abstracts away low-level execution details and focuses on the primary drivers of system-level performance and cost, namely computational capacity, network latency and bandwidth, and resource pricing. This design choice facilitates systematic what-if analyses across heterogeneous Cloud–Edge architectures while maintaining transparency and interpretability.

Each simulation scenario combines a deterministic parallel workload, modeled as a task graph, with a hierarchical representation of the Cloud–Edge infrastructure. Computing devices are arranged in layers spanning IoT, Fog, and Cloud resources, with increasing computational power and network capacity along the hierarchy. The infrastructure is modeled as a graph whose nodes correspond to devices or routers and whose edges represent network links characterized by latency and bandwidth (Figure 1).

This representation allows execution paths, end-to-end delays, and data transfer costs to be evaluated consistently across different deployment regimes.

Within each scenario, three functional roles are defined: a main server responsible for coordination and scheduling, a data source providing input data, and a data collector receiving computation results. These roles may be co-located on the same device or assigned to different layers of the infrastructure, enabling the exploration of alternative deployment strategies without modifying the underlying workload.

Against this backdrop, the central research question addressed in this paper is: how do scheduling policies and network conditions jointly influence execution time and monetary cost for parallel workloads deployed across the Cloud–Edge continuum? A particular focus is placed on assessing whether strategies that optimize a single objective, such as computational speed or resource cost, remain effective when communication latency and data transfer overheads become significant.

The contributions of this work are threefold. First, we present a simulation-based framework for studying Cloud–Edge execution behavior at a level of abstraction suitable for large-scale comparative analyses. Second, we provide a statistically grounded experimental study that highlights how communication effects shape execution time and reduce the impact of computation-centric scheduling across deployment regimes. Third, by relying on deterministic workloads and Monte Carlo experimentation, the analysis makes regime transitions and performance variability explicit.

The remainder of the paper is organized as follows. Section 2 and Section 3 review background material and related work. Section 4 and Section 5 introduce the system and execution models together with the performance indicators considered. Section 6 describes the experimental design, while Section 7 presents and discusses the results. Section 8 closes the paper and outlines directions for future work.

2. Background

The Cloud–Edge continuum denotes a class of hierarchical deployments in which computation is distributed across multiple layers, from resource-constrained IoT devices to intermediate Fog nodes and centralized Cloud data centers. These architectures are typically adopted to reduce latency and to limit network traffic, particularly for data-intensive or geographically distributed applications.

Performance gains in such settings are not guaranteed. Computing devices differ in processing capability and usage cost, while network links exhibit heterogeneous latency and bandwidth characteristics. Execution time therefore depends not only on processor speed but also on how often and how far data must travel across the hierarchy. In many realistic configurations, communication delays accumulate along dependency chains and can account for a large portion of the overall completion time. This heterogeneity motivates the explicit inclusion of network effects when analyzing scheduling behavior.

Distributed workloads are commonly modeled as directed acyclic graphs (DAGs), where nodes represent computational tasks and edges encode precedence constraints together with the associated data transfers. Both the topology of the DAG and the volume of data exchanged along its edges influence the extent to which execution time is affected by network conditions.

For data-intensive or iterative workloads, repeated transfers between tasks placed on different layers can amplify latency effects. In these cases, performance becomes increasingly sensitive to communication properties rather than to raw computational speed. Evaluating scheduling policies without considering these structural aspects may therefore lead to incomplete or misleading conclusions.

Task scheduling concerns the assignment of ready tasks to available computing devices under objectives such as minimizing completion time or reducing monetary cost. Although a wide range of scheduling algorithms has been proposed, many practical systems rely on relatively simple heuristics based on processor speed, resource cost, or static device attributes.

These heuristics typically assume that computation represents the primary bottleneck. In heterogeneous Cloud–Edge environments, however, variability in network conditions can significantly alter execution dynamics. Latency accumulation and repeated data transfers may counterbalance the advantages of selecting faster or less expensive devices. Examining the behavior of baseline scheduling strategies under explicit communication modeling is therefore necessary to understand system-level performance regimes.

Analytical analysis of heterogeneous Cloud–Edge systems quickly becomes intractable once computation, communication, and scheduling decisions interact. Discrete-event simulation provides a practical alternative, allowing these elements to be represented explicitly while retaining experimental control.

Simulation supports systematic variation in architectural parameters and deployment choices, enables Monte Carlo replication, and exposes variability through distributional analysis. For comparative studies that focus on regime behavior rather than on identifying globally optimal solutions, this level of abstraction offers a tractable and reproducible approach.

Within this framework, the present work relies on simulation to study how commonly used scheduling heuristics behave across Cloud, Fog, and IoT deployments. The aim is not to develop improved schedulers, but to identify the conditions under which communication or computation becomes the dominant performance constraint and to clarify the resulting implications for cost–performance trade-offs.

3. Related Work

The execution of data-intensive workloads on distributed and heterogeneous infrastructures has been examined from several angles, including placement, workflow scheduling, performance modeling, and system design. This work is related to these directions, but looks at a different question. The emphasis is not on introducing new schedulers or optimization techniques, but on observing how commonly used policies behave when network conditions are treated as a primary factor rather than a secondary one.

A related study is presented by Mongiardo et al. [1], where application placement is analyzed in the presence of resource overbooking. That work focuses on how oversubscription affects capacity and placement decisions. Here, the architecture is kept fixed, and attention is shifted to what happens during execution after scheduling has been applied. In addition, latency and bandwidth are not central variables in [1], whereas in the present analysis latency can become the dominant contributor to execution time even when computational resources are available.

Cooperative execution at the edge is examined by Zeng et al. [2], who propose an adaptive method for partitioning DNN inference across heterogeneous devices. Their work concentrates on distributing computation efficiently within a specific application domain. The present study differs in scope, as it considers general task graphs and focuses on how execution behavior changes across Cloud–Edge deployments when communication parameters are varied explicitly.

Service placement and scheduling are addressed by Li et al. [3], who introduce a cooperative and deadline-driven approach. Their objective is to improve service completion under timing constraints through coordinated decision mechanisms. While both works consider distributed edge environments, the focus here is not on optimizing placement decisions, but on understanding how execution unfolds once a policy has been selected.

Programming abstractions for parallel data processing are discussed by Bandirali et al. [4], who propose vendor-agnostic primitives to improve portability across heterogeneous platforms. Their contribution is mainly concerned with expressiveness. The execution patterns they describe, however, often involve parallel phases followed by aggregation, which are also considered in CLOWNSim. The difference lies in the perspective: here, the same patterns are examined under deployment conditions where communication delays are non-negligible.

Shang et al. [5] provide an empirical comparison of sequential and parallel implementations of K-means. Their results show performance gains from parallelization, but the experiments are conducted in relatively homogeneous environments. In this work, the algorithmic details are abstracted away, and the same parallel structure is evaluated across a Cloud–Edge hierarchy, where communication costs can outweigh computation.

Workflow scheduling in the Cloud–Edge continuum is reviewed by Zanussi et al. [6]. Their survey outlines architectural issues and scheduling strategies in heterogeneous settings. Although network heterogeneity is mentioned, latency and bandwidth are not explored systematically. In the present study, the situation is reversed: scheduling policies are fixed and kept simple, while network parameters are varied to observe how scheduler behavior changes across different regimes.

Rac and Brorsson [7] address cost-aware scheduling, balancing performance and monetary objectives. Their focus is on decision-making. The analysis here instead looks at the execution phase, where communication overhead accumulates and can alter the outcome even after a policy has been chosen.

Recent work has explored adaptive and learning-based scheduling in edge environments. Zheng et al. [8] apply deep reinforcement learning to workload scheduling, aiming to balance resource utilization and service performance under dynamic conditions. Similarly, Shahidani et al. [9] propose a reinforcement learning approach for multi-objective scheduling across Edge–Fog–Cloud layers. These methods introduce adaptive control mechanisms, but the interaction between network parameters and execution behavior remains embedded within the learning process. In contrast, the present study keeps scheduling fixed to make these effects more directly observable.

Service placement under communication and resource constraints is also studied by Sarrafzade et al. [10], who propose a genetic-based approach for fog environments. Their work emphasizes optimization of placement decisions with respect to delay and resource usage. The present analysis instead focuses on execution behavior after placement and scheduling have been determined.

Several works adopt analytical or hybrid models to predict performance. Ardagna et al. [11] estimate execution time by combining system and application descriptors, while Lattuada et al. [12] study cost–performance trade-offs for Spark. These approaches are useful for planning, but they typically rely on simplified network assumptions and focus on centralized infrastructures.

More formal models are considered by Gianniti et al. [13], who use Fluid Petri Nets to represent MapReduce and Spark workloads. These models can capture system dynamics in detail, but require careful calibration and modeling effort, which makes large exploratory studies less convenient. CLOWNSim follows a different path, favoring flexibility and enabling extensive Monte Carlo experiments in which latency and bandwidth are varied explicitly.

Optimization and learning-based techniques have also been explored. Guerrero et al. [14] study placement using a distributed genetic algorithm, focusing on convergence and solution quality. Tang et al. [15] apply reinforcement learning to workflow scheduling in multi-Cloud environments. These approaches introduce adaptive mechanisms, but in doing so, they make it harder to separate the effect of network parameters from the behavior of the optimization method itself.

The practical challenges of experimentation in the Cloud continuum are discussed by Casino et al. [16], who point out the fragmentation of available testbeds and the difficulty of reproducing results. This motivates the use of simulation, which allows controlled and repeatable exploration, even if it does not capture all aspects of real deployments.

Serverless execution has also been studied in this context. Matricardi et al. [17] and Bocci et al. [18] focus on orchestration and secure placement of FaaS applications, while Raith et al. [19] use trace-driven simulation. These works target a specific execution model. In contrast, CLOWNSim supports general task graphs with explicit data transfers. A concise overview of scheduling problems in the computing continuum is provided by Mehran et al. [20]. Their survey outlines the main challenges involved in mapping distributed applications across Cloud, Fog, and Edge resources, with attention given to heterogeneity and application requirements. Its contribution is mainly classificatory and synthetic. By contrast, the present work does not survey scheduling methods broadly, but examines, through simulation, how simple scheduling policies behave when latency and bandwidth are treated as explicit and variable factors in execution.

Table 1. Summary of related work: strengths and limitations.

Authors (Year)	Strengths	Limitations
Mongiardo et al. (2025) [1]	Placement under overbooking.	Network effects not primary.
Zeng et al. (2020) [2]	Adaptive DNN inference across edge devices.	Limited to specific application domain.
Li et al. (2021) [3]	Deadline-aware cooperative scheduling.	Focus on optimization rather than execution behavior.
Bandirali et al. (2018) [4]	Portable parallel primitives.	Limited focus on execution behavior.
Shang et al. (2021) [5]	Empirical evaluation of parallel algorithms.	Homogeneous environments.
Zanussi et al. (2024) [6]	Survey of Cloud–Edge scheduling.	Limited systematic treatment of networks.
Rac and Brorsson (2024) [7]	Cost-aware scheduling.	Limited execution-phase analysis.
Zheng et al. (2022) [8]	DRL-based scheduling in Edge environments.	Network effects embedded in learning process.
Shahidani et al. (2023) [9]	RL-based multi-layer scheduling.	Limited isolation of network effects.
Sarrafzade et al. (2022) [10]	Genetic-based Fog placement optimization.	Focus on placement decisions.
Ardagna et al. (2021) [11]	Predictive performance modeling.	Limited treatment of Cloud–Edge settings.
Lattuada et al. (2020) [12]	Cost–performance modeling for Spark.	Simplified network assumptions.
Gianniti et al. (2017) [13]	Uses Fluid Petri Nets for detailed performance modeling.	Requires calibration and modeling effort.
Guerrero et al. (2024) [14]	Genetic optimization for placement.	Network effects not isolated.
Tang et al. (2024) [15]	RL-based workflow scheduling.	Hard to separate structural effects.
Casino et al. (2025) [16]	Analysis of experimental challenges.	Does not address execution modeling.
Matricardi et al. (2023) [17]	Simulates FaaS orchestrations across Cloud–Edge layers, enabling controlled evaluation of serverless execution behavior.	Focused on serverless orchestration; less suited to generic task graphs and broader workflow structures.
Bocci et al. (2023) [18]	Introduces declarative and security-aware placement for FaaS orchestrations in the Cloud–Edge continuum.	Emphasizes secure placement decisions; communication-driven execution effects remain secondary.
Raith et al. (2023) [19]	Provides a trace-driven simulation framework for serverless Edge platforms with realistic workload modeling.	Trace dependence constrains systematic exploration of alternative architectures and network regimes.
Mehran et al. (2023) [20]	Provides a concise survey of scheduling challenges across the computing continuum.	Survey-oriented; does not isolate execution-phase network effects through simulation.

summarizes the main strengths and limitations of the works discussed above.

Much of the existing literature concentrates on improving placement or scheduling decisions, or relies on models where network effects are simplified or embedded within more complex mechanisms. The present study instead examines what happens when latency and bandwidth are treated explicitly and allowed to vary. Under these conditions, behaviors emerge that differ from those expected in computation-centered settings, suggesting that communication should be considered a primary factor in the design of Cloud–Edge systems.

4. System Model

This section describes the modeling assumptions adopted in CLOWNSim for applications and execution environments, as well as the way their interaction is represented across the Cloud–Edge continuum. The model is deliberately selective: it focuses on the components that most strongly influence execution time and monetary cost for parallel, data-intensive workloads, while omitting low-level details that would obscure system-level behavior.

The intent is not to reproduce the behavior of a specific platform at fine granularity, but to provide a controlled and reproducible setting in which architectural structure, network conditions, and scheduling choices can be varied independently. All modeled quantities correspond either to observable system properties or to parameters that can be modified through deployment and configuration decisions.

Applications are represented as directed acyclic graphs (DAGs), in which nodes denote computational tasks and edges encode precedence constraints and data dependencies. Each task is described by a processing demand (expressed in millions of instructions), an optional executable code payload to be transferred prior to execution, an input data volume, and an output data volume.

Tasks are treated as atomic units. No internal parallelism, runtime adaptation, or speculative execution is modeled. This abstraction isolates the effects of task placement and data movement from algorithm-specific optimizations.

Many Cloud–Edge workloads follow a recurring structure composed of an initial sequential stage, a parallel phase, and a final aggregation step. This pattern appears in analytics pipelines, clustering algorithms, and distributed optimization methods. A minimal example is shown in Figure 2.

Iterative workloads are represented through explicit loop unrolling. For a fixed number of iterations, cyclic workflows are transformed into expanded DAGs with a deterministic structure, as illustrated in Figure 3. This approach makes cumulative execution time and cost explicit and avoids conflating infrastructural effects with algorithmic variability.

Repeated traversal of identical dependency paths causes latency to accumulate across iterations, particularly at synchronization points. This mechanism amplifies the influence of communication and plays a central role in the execution regimes observed in the experimental analysis.

Each task executes through a sequence of logical stages: retrieval of executable code from the Main Server (MS), retrieval of input data from the Data Source (DS), computation on the assigned device, and transmission of output data to the Data Collector (DC). Depending on the task specification, some stages may be absent.

Computation time is modeled as

$$T_{\mathrm{comp}}={\displaystyle \frac{I}{P}},$$

where I denotes the processing demand and P the processing rate of the assigned device. For a data transfer of size D over a path with bandwidth B and end-to-end latency L, communication time is given by

$$T_{\mathrm{net}}=L+{\displaystyle \frac{D}{B}}.$$

For multi–hop communication paths, latency contributions are additive and the effective bandwidth is determined by the bottleneck link. Tasks execute without preemption, yielding deterministic timing once a task has been dispatched.

The execution environment is modeled as a layered Cloud–Edge hierarchy comprising IoT devices, Fog nodes, and Cloud data centers. Each layer may contain multiple homogeneous device classes, characterized by processing capacity, setup overhead, usage cost, and compatibility attributes.

Layers are connected by network links described by latency and bandwidth distributions. The topology is restricted to a tree, ensuring a unique communication path between any pair of devices and simplifying the evaluation of end-to-end delays. This assumption reflects common hierarchical deployment patterns and highlights the cumulative impact of latency in iterative workloads.

Three logical roles are associated with specific devices: the Main Server (MS), responsible for coordination and scheduling; the Data Source (DS), which provides input data; and the Data Collector (DC), which receives output results. These roles may be co-located or assigned to different layers, allowing alternative deployment strategies to be explored under a fixed workload structure.

When all predecessors of a task have completed, the task becomes ready for execution and is assigned to a compatible device according to a scheduling policy. The policies considered include random assignment and simple heuristics based on processing speed or resource cost.

Scheduling decisions do not incorporate explicit estimates of downstream communication costs or latency accumulation across iterations. This choice reflects the behavior of many practical systems, where decisions rely on local resource descriptors rather than on end-to-end communication modeling.

Device usage and monetary cost are tracked throughout execution. Network contention is not modeled explicitly; instead, effective latency and bandwidth values are sampled from the scenario specification, introducing controlled stochastic variability.

Processing rates, setup delays, bandwidth, and latency may follow fixed, uniform, exponential, or Weibull distributions. Independent pseudo-random streams are used for computation, communication, and scheduling decisions to ensure reproducibility.

Each scenario is evaluated through Monte Carlo replication, producing empirical distributions of performance metrics. Variability across runs is treated as informative, as it reveals distinct execution regimes, including computation-dominated and communication-dominated behavior.

Architectures and workloads are specified through declarative JSON configuration files. This approach supports reproducibility, automated parameter sweeps, and traceability of ethe xperimental results.

Overall, the model provides a level of abstraction suitable for systematic Cloud–Edge studies while keeping performance and cost trade-offs interpretable and attributable.

The proposed model deliberately abstracts several aspects of real Cloud–Edge systems. In particular, resource contention and network congestion are not modeled explicitly: latency and bandwidth are sampled independently, and no queueing effects are considered. As a consequence, the results should be interpreted as characterizing structural performance regimes rather than precise system-level predictions.

The network topology is restricted to a tree, yielding a single communication path between devices. This excludes routing variability, multipath communication, and failure scenarios.

The execution model assumes non-preemptive tasks and does not represent concurrent execution on multiple devices, thereby neglecting scheduling queues and resource contention effects.

Furthermore, the scheduling policies considered do not incorporate explicit estimates of communication costs. The analysis therefore does not extend to network-aware or DAG-based scheduling algorithms, but instead isolates the behavior of simple, widely used heuristics under stochastic network conditions.

These simplifications are intentional and support the goal of isolating the interaction between workload structure, placement, and communication variability. However, they limit the direct applicability of the results to highly dynamic or congestion-sensitive environments.

5. Model-Driven Performance Indicators and Scheduling Policies

Because CLOWNSim operates as a discrete-event simulator with stochastic elements, execution behavior cannot be described by single trajectories or point estimates. Observed performance arises from the interaction between workload structure, scheduling decisions, and network conditions. The indicators introduced in this section are selected to capture these interactions with limited interpretation overhead and to support comparisons across Cloud, Fog, and IoT deployments.

Instead of defining a large set of metrics or assessing scheduler optimality, the analysis concentrates on a small number of model-driven quantities that are sufficient to characterize execution regimes and cost–performance trade-offs along the Cloud–Edge continuum.

5.1. Primary Time and Cost Indicators

The principal performance indicator is the makespan, defined as the time elapsed between the start of the first task and the completion of the final task in the application DAG:

$$M=t_f-t_0.$$

Makespan captures end-to-end responsiveness and is particularly sensitive to synchronization points and latency accumulation in iterative workloads.

In addition to execution time, the simulator records the monetary cost incurred during task execution. Cost is examined jointly with makespan to identify situations in which shorter execution times are obtained at higher economic expense, as well as regimes in which scheduling choices have limited influence on cost.

5.2. Execution Time Decomposition

To support interpretation of makespan variations, execution time is decomposed into three components that follow directly from the execution model:

• Setup time, including code staging and initialization;
• Computation time on the selected devices;
• Transfer time associated with data movement across the network.

This decomposition enables the distinction between computation-dominated and communication-dominated executions and allows the balance between these components to be tracked across deployment regimes.

For comparisons across scenarios with different absolute durations, the normalized transfer share is introduced:

$$S_{\mathrm{transfer}}={\displaystyle \frac{T_{\mathrm{transfer}}}{M}},$$

where $T_{\mathrm{transfer}}$ denotes the cumulative time spent on data transfers. This ratio provides a concise indicator of communication dominance.

5.3. Scheduling Policies

When a task becomes ready for execution, it is assigned to a compatible device according to a scheduling policy, subject to availability constraints. Three simple and interpretable heuristics are considered:

• Fastest-first, which favors devices with higher processing speed;
• Cheapest-first, which prioritizes devices with lower usage cost;
• Random, which serves as an uninformed baseline.

These policies are not intended to reflect state-of-the-art schedulers. They are used as probes to identify when computation-centric intuition remains valid and when it fails once communication effects are modeled explicitly.

Scheduling decisions do not incorporate forecasts of downstream communication costs or latency accumulation across iterations. Network effects therefore emerge as consequences of placement choices rather than as quantities explicitly optimized by the scheduler, reflecting common practice in operational systems.

5.4. Distributional and Trade-Off Analysis

Because processing rates, setup delays, bandwidth, and latency are modeled as stochastic variables, both makespan and cost are random outcomes. Each scenario is evaluated through multiple Monte Carlo replications, producing empirical distributions rather than single values.

Distributional representations, including boxplots, empirical cumulative distribution functions, and confidence intervals, are used to compare scheduling policies and deployment regimes. These views reveal overlaps, regime transitions, and saturation effects that are not apparent from mean values alone.

To examine the interaction between time and cost objectives, Pareto relationships in the makespan–cost plane are also considered. These relationships indicate whether scheduling choices generate meaningful trade-offs or converge to indistinguishable behavior once dominant constraints emerge.

5.5. Communication Dominance Diagnostics

Finally, scatter plots relating transfer share to makespan are used as diagnostic tools to interpret execution regimes. By stratifying these plots according to deployment setting, it becomes possible to visualize the shift from partially computation-sensitive behavior in Cloud environments to regimes in which makespan is closely coupled to communication or resource constraints in Fog and IoT deployments.

The observed execution regimes can be interpreted in terms of the relative contribution of communication and computation to the overall makespan. In particular, the normalized transfer share $S_{transfer}$ provides a useful indicator for distinguishing between regimes.

When $S_{transfer}$ remains relatively low, execution is primarily driven by computation and scheduling decisions retain some influence. As $S_{transfer}$ increases, communication delays become dominant, and the impact of computation-oriented scheduling heuristics progressively diminishes. In the experimental results, Fog deployments consistently exhibit higher transfer shares and greater variability, indicating a transition toward communication-dominated behavior, whereas IoT deployments remain characterized by high makespan values but comparatively lower transfer shares, reflecting computation-limited execution.

Although the present study does not define sharp numerical thresholds, these observations suggest that regime transitions occur when communication time becomes comparable to or exceeds computation time. The transfer share can therefore be used as a diagnostic indicator to identify operating conditions in which scheduling strategies are likely to have limited effectiveness.

6. Experimental Setup

This section describes the experimental campaign carried out using CLOWNSim (available at https://github.com/EBarbierato/prin_A-Reproducible-Monte-Carlo-Framework-for-Evaluating-). The aim is not to tune individual configurations or to identify optimal operating points, but to examine how scheduling decisions interact with network effects across different regions of the Cloud–IoT continuum under controlled and reproducible conditions.

The experimental design follows a factorial structure in which deployment regime, scheduling policy, and stochastic variability are varied independently. This separation makes it possible to observe network effects directly, without mixing them with differences in computational performance or resource pricing.

6.1. Cloud–Edge Architecture Configuration

All experiments rely on a hierarchical Cloud–Edge architecture composed of four layers: Cloud, Fog Remote, Fog Near, and Edge. Each layer contains one or more homogeneous classes of devices, described by their processing capacity, usage cost, and network interfaces.

Communication within a layer is modeled through local links, while adjacent layers are connected via backbone links. Each network link is characterized by latency and bandwidth parameters. To ensure deterministic routing and timing, the network topology is constrained to a tree, yielding a single communication path between any pair of devices.

Three deployment regimes are defined by co-locating the main server (MS), the data source (DS), and the data collector (DC) on the same layer:

• Cloud placement, representing centralized execution with low latency and high bandwidth;
• Fog placement, representing intermediate execution with higher latency and more limited bandwidth;
• IoT placement, representing highly distributed execution under heterogeneous and constrained network conditions.

These regimes are treated as abstract experimental scenarios capturing qualitatively distinct operating conditions rather than as replicas of specific real-world deployments.

6.2. Workload Modeling

The workloads follow an iterative parallel structure inspired by MapReduce-style processing and centroid-based clustering. Each application is represented as a directed acyclic graph (DAG) obtained by explicitly unrolling a fixed number of iterations.

Each iteration includes an initialization task executed on the MS, a collection of parallel tasks operating on disjoint data partitions, an aggregation task, and a final task producing the output. By unrolling iterations, all task dependencies and data transfers are made explicit, allowing scheduling decisions and synchronization points to be handled deterministically.

In Fog and IoT placements, communication paths typically span multiple layers. As a result, latency accumulates across iterations instead of appearing as a single, upfront cost.

6.3. Impact of Scheduling Policies

To assess the impact of scheduling decisions, three simple and interpretable heuristics are considered:

• Random, which selects uniformly among eligible devices;
• Fastest, which favors devices with higher processing speed;
• Cheapest, which favors devices with lower usage cost.

These policies correspond to different decision logics—uninformed, performance-oriented, and cost-oriented—and are used to probe how computation, communication, and pricing interact across deployment regimes. None of the policies incorporates explicit knowledge of future communication costs; latency accumulation and repeated data transfers therefore arise as outcomes of placement decisions.

6.4. Stochastic Evaluation and Reproducibility

All experiments are conducted through discrete-event stochastic simulation. Processing demands, setup delays, bandwidth, and latency are sampled from probability distributions, so repeated executions of the same configuration produce different outcomes.

Each scenario is evaluated through multiple Monte Carlo replications using independent random seeds. Makespan, cost, and execution-time components are thus treated as random variables, and the analysis is based on their empirical distributions.

The experimental campaign includes more than one thousand simulation runs, covering all combinations of deployment regime, scheduling policy, and random seed. Architecture descriptions, workload specifications, and result traces are generated automatically and archived, ensuring full reproducibility of the study.

7. Results and Performance Analysis

This section examines the execution behavior observed in the Monte Carlo experiments introduced in Section 6. The analysis does not aim to provide an exhaustive statistical summary. Instead, attention is directed toward structural effects, namely how dominant performance constraints change along the Cloud–Edge continuum and how these changes influence the impact of computation-oriented scheduling policies.

Unless otherwise specified, all results aggregate independent replications of the same experimental configuration.

7.1. Baseline Behavior Under Cloud Placement

The Cloud placement is used as a reference regime. Under centralized resources and favorable network conditions, execution times show limited sensitivity to the choice of scheduling policy. All heuristics operate within a similar performance region, and differences in makespan and billed cost remain modest.

For this reason, detailed distributional plots for the Cloud scenario are not reported. The Cloud configuration establishes a baseline in which scheduling heuristics behave in line with computation-centric expectations, while already indicating that communication effects restrict the potential gains obtainable from faster devices.

7.2. Cost Reduction Versus Execution Time Across Placement Regimes

Shifting computation away from the Cloud leads to lower billed cost, but also changes the dynamics of execution. Figure 4 and Figure 5 report the mean billed cost together with 95% confidence intervals for Fog and IoT placements.

Execution on Fog and IoT resources is consistently cheaper than in the Cloud. This effect is stable across replications. The reduction in cost, however, is associated with longer completion times. The mechanisms responsible for this increase differ between Fog and IoT regimes, as discussed below.

7.3. Execution-Time Composition and Regime Shifts

To identify which components drive makespan, execution time is decomposed into setup, computation, and data transfer contributions. Figure 6 presents the relative breakdown under Cloud placement, while Figure 7 and Figure 8 report the same decomposition for Fog and IoT placements.

In the Cloud regime, computation and data transfer account for comparable fractions of the makespan. Even under favorable network conditions, communication constrains the gains obtained by prioritizing faster devices.

Under Fog placement, communication becomes a dominant contributor to execution time. Higher latency and repeated data transfers diminish the influence of scheduling decisions and introduce noticeable variability across runs.

The IoT regime exhibits a different pattern. Execution time is largely driven by computation on constrained devices, while communication plays a smaller role. This represents a distinct regime in which processing scarcity, rather than network delay, becomes the primary limitation.

7.4. Transfer Share Versus Makespan

The relationship between communication intensity and execution time is further explored by plotting transfer share against makespan. Figure 9 and Figure 10 illustrate these patterns for Fog and IoT placements.

In the Fog regime, makespan increases with transfer share. Variability in network conditions generates distinct clusters that correspond to different network realizations induced by stochastic latency and bandwidth, rather than to different scheduling policies. Communication thus acts both as a source of delay and as a driver of dispersion.

In the IoT regime, transfer share remains relatively low and concentrated, while makespan stays elevated. This confirms that limited processing capacity, rather than communication, determines overall completion time in this setting.

7.5. Observed Execution Regimes

The experiments reveal three qualitatively different regimes along the Cloud–Edge continuum. Cloud execution operates in a mixed computation–communication setting with modest sensitivity to scheduling. Fog execution is characterized by communication dominance and higher variability, which reduces the practical impact of computation-oriented heuristics. IoT execution is driven primarily by limited processing capacity, so both scheduling and communication effects have reduced influence.

These shifts clarify why improvements in scheduling logic alone are insufficient to explain performance trends across heterogeneous Cloud–Edge deployments.

The current model leaves out any explicit representation of contention in the network or of concurrent transfers. For each communication event, latency and bandwidth are drawn independently, and no mechanism accounts for queueing or shared resources. Because of this, simultaneous flows do not interact: effects such as congestion or competition for bandwidth simply do not appear.

With this choice, the variability seen in the results comes from fluctuations in link conditions, not from contention dynamics. In actual deployments, overlapping transfers can introduce non-linear delays, for instance through queueing or short-term saturation. Independent sampling cannot reproduce those effects. The results then should be read as describing how the system behaves under uncertain but independent network conditions, not as detailed predictions for scenarios where contention plays a role.

Still, the approach can serve as a first approximation of heterogeneous and time-varying networks. Each transfer is assigned an effective latency and bandwidth sampled from a distribution, which makes it possible to explore variability and shifts between regimes while keeping the experiments controlled and repeatable. Incorporating explicit contention and queueing would be a natural next step.

The network itself is represented as a hierarchical tree, so that there is a single path between any two devices. This simplifies the analysis of end-to-end delay and allows us to identify how latency accumulates along chains of dependent tasks. In practice, Fog and IoT systems often look more like meshes, where multiple routes can be used.

When multiple paths exist, routing can sometimes reduce accumulated latency, either by choosing shorter paths or by avoiding congested links, or even by splitting traffic. Under these conditions, the bottlenecks observed in the Fog regime may be less severe. The results here are therefore more indicative of hierarchical deployments or settings where routing options are limited. Extending the model to include mesh topologies and adaptive routing would make it possible to examine these effects more directly.

The scheduling policies used in this study do not take communication costs or data locality into account. Tasks are assigned without considering how far the data must travel or how many hops are involved. This makes it easier to focus on the behavior of computation-oriented heuristics once communication is modeled explicitly.

One possible extension is to introduce scheduling strategies that are aware of network conditions, for example, by considering transfer delays or distances. Such strategies could reduce the latency buildup seen in the Fog regime, especially for workloads with frequent synchronization or repeated exchanges. Tasks might be placed closer to where the data is produced or aggregated, which could shorten transfers and reduce variability. At the same time, this may lead to trade-offs, such as lower computational efficiency or higher resource costs when nearby devices are less capable.

The behavior observed across the Cloud–Edge continuum can be read in terms of how communication and computation balance each other. Depending on whether data transfer time or processing time dominates, the system operates in different regimes. Although the workload structure is fixed, this balance changes indirectly through stochastic latency and bandwidth, as well as through the deployment setup.

Within the proposed framework, this balance can be adjusted more directly by varying data sizes and processing requirements separately. A more systematic exploration along these dimensions would help clarify where the transitions between regimes occur and would extend the present analysis.

8. Conclusions

This work examined how scheduling policies interact with network behavior in the execution of parallel, data-intensive workloads across the Cloud–Edge continuum. The analysis focused on whether scheduling strategies that perform well under computation-centric assumptions continue to do so once communication effects are explicitly represented under non-ideal network conditions. The results indicate that the role of scheduling varies with the deployment regime. In centralized Cloud settings, scheduling has a modest yet observable impact on makespan and cost, though communication overhead already limits the advantage of selecting faster resources. In Fog deployments, execution shows higher variability and is more affected by stochastic network conditions than by the choice of scheduling rule. In IoT settings, limited processing capacity becomes the main constraint, with computation largely determining makespan and communication contributing less. Moving along the Cloud–Edge continuum, the main performance limitation changes in character. In the Cloud, computation and communication interact; in the Fog, variability is driven mainly by communication; in IoT scenarios, the scarcity of computational resources dominates. Under these circumstances, scheduling policies alone do not provide a sufficient explanation of performance trends. Their effect depends on the regime in which execution takes place. Two implications follow from these observations. Performance optimization in Cloud–Edge systems cannot be approached through scheduler design alone, since it depends also on workload structure, placement, and network properties. Moreover, conclusions drawn from centralized Cloud environments do not transfer directly to heterogeneous or constrained settings. From a methodological standpoint, the combination of discrete-event simulation and Monte Carlo experimentation proves useful for examining behavior under controlled stochastic variability. The framework makes it possible to observe when simple heuristics stop being effective and under which conditions this occurs.

The scheduling strategies considered here are deliberately simple and do not use information about communication costs or data locality. This helps isolate baseline behavior, but also makes visible the limits of computation-oriented approaches when communication becomes dominant. Extending the model to include network-aware scheduling, for example, by incorporating transfer delays or distances, would allow these effects to be addressed more directly. Such strategies could reduce latency accumulation in Fog scenarios, although they may introduce trade-offs in terms of computational efficiency or resource usage. The current framework can be used to study these aspects.

The evaluation relies entirely on simulation and does not use real-world traces or deployments. This allows for controlled and reproducible experiments, but restricts direct empirical validation. The results should therefore be read as comparative and structural, not as precise predictions. Additional factors such as contention, congestion, or workload variability may arise in practice and are not fully represented in the current model. Future work will extend the framework along several directions. Network-aware and adaptive scheduling strategies will be introduced to evaluate their behavior under communication-dominated conditions. The model will also be expanded to include dynamic workload arrivals and stochastic task graphs. At present, iterative workloads are modeled through explicit loop unrolling with a fixed number of iterations. This supports deterministic task graphs and a controlled analysis of latency accumulation, but does not capture behaviors such as early stopping or variable iteration counts. Allowing dynamic or stochastic iteration patterns would provide a closer representation of real-world machine learning workloads and remains an open direction for further study.