arXiv CSopen access

A Taxonomy of Performance Metrics for the Distributed Computing Continuum

A Taxonomy of Performance Metrics for the Distributed Computing Continuum Praveen Kumar Donta1*, Boris Sedlak2 , Alfreds Lapkovskis1 , Alaa Saleh3 , Ying Li4 , Victor Casamayor Pujol5 , Ilir Murturi6 , Manuel Otero Barbasan7 , Schahram Dustdar2,8

arXiv:2607.28407v1 [cs.DC] 30 Jul 2026

1*

Department of Computer and Systems Sciences, Stockholm University, NOD Borgarfjordsgatan 12, Stockholm, 106 91, Stockholm, Sweden. 2 Distributed Systems Group, TU Wien, Argentinierstrasse 8 / 194-02, Vienna, 1040, Wien, Austria. 3 Department of Computer Science , University of Helsinki, Fabianinkatu 33, Helsinki, 00014, Helsinki, Finland. 4 School of Computer Science and Engineering , Northeastern University, No. 195 Chuangxin Road, Shenyang, 110169, Liaoning, China. 5 Department of Engineering, Universitat Pompeu Fabra, Roc Boronat, 138, Barcelona, 08018, Barcelona, Spain. 6 Department of Mechatronics, University of Prishtina, Rr. George Bush, Nr.31, Prishtina, 10000, Prishtina, Kosovo. 7 Department of Computer Languages and Systems, Universidad de Sevilla, C. San Fernando 4, Sevilla, 41004, Sevilla, Spain. 8 ICREA, Barcelona, Passeig Lluı́s Companys 23, Barcelona, 08010, Barcelona, Spain.

*Corresponding author(s). E-mail(s): [email protected]; Contributing authors: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Abstract Performance evaluation is essential for understanding, comparing, and improving computing systems, including Distributed Computing Continuum Systems (DCCS). In recent years, computational requirements have changed substantially

1

with the growth of artificial intelligence and large-scale data-driven applications. These application tasks are increasingly distributed between resource-intensive data centers and resource-constrained edge environments. In this context, novel computing continuum architectures and algorithms are emerging, creating a need for transparent and consistent performance evaluation. However, existing evaluation practices often focus on isolated dimensions, such as computation, networking, energy efficiency, or application-level quality, and therefore provide only a partial view of cross-layer DCCS behavior. This paper presents a structured taxonomy of performance metrics for DCCS. The taxonomy organizes metrics into computing-level, network-level, and application/user-level categories, while also highlighting emerging dimensions such as sustainability, observability, adaptability, data locality, migration awareness, and continuum fragmentation. Further, we provide mathematical formulations and discuss their relevance to heterogeneous and dynamic continuum environments. We also summarize metric acquisition requirements in terms of acquisition scope, acquisition phase, and measurement method. These requirements help clarify whether a metric can be collected from a single node, multiple nodes, or the full system, and whether it is more suitable for operational monitoring or experimental evaluation. Keywords: Performance Measuring, Edge Intelligence, Distributed Computing Continuum Systems, Amdahl’s Law

1 Introduction Distributed computing continuum systems (DCCS) exemplify a profound shift in the computing paradigm, ushering in an era where traditional boundaries blur and dynamic synergies emerge [1, 2]. This paradigm envisions a seamless continuum of computing resources that includes data centers, cloud infrastructures, edge computing nodes, and IoT devices. It allows applications and services to intelligently assign tasks, data, and services across the computing continuum, unlike a uniform computing model [3]. Traditionally, data centers provided massive processing and storage capabilities, while cloud platforms extended this reach and provided scalable, on-demand resources [4]. The edge computing environment facilitates low-latency processing by putting data sources close to the data processors, minimizing data transit times, and improving applications’ response times [5–7]. In addition to this continuum, a growing IoT system introduces distributed sensors and actuators. These sensors generate huge amounts of real-time data that can be analyzed and responded to accordingly [8]. In this computing paradigm, applications take advantage of the unique strengths of each computing node and dynamically allocate workloads along the computing continuum. For example, limited data and time-critical applications like autonomous vehicles or healthcare flourish at the edge. In contrast, data-intensive analytics such as artificial intelligence (AI), Machine learning (ML), and Large language models (LLMs) leverage the computational power of cloud data centers [9]. This way maximum benefit is achieved by maximizing efficiency and resource usage, reducing operating costs, and

2

energy consumption [10]. However, measuring the efficiency and performance of DCCS is challenging due to the vast variety of heterogeneous resources. Distributed Computing Continuum Systems (DCCS) represent a shift from centralized computing toward a heterogeneous and distributed execution model that spans cloud data centers, fog nodes, edge servers, mobile devices, and Internet of Things (IoT) devices [1, 2]. The DCCS paradigm enables applications to place computation, data, and services across multiple layers of the continuum according to application requirements and resource availability [3]. Traditionally, data centers and cloud platforms provided large-scale processing, storage, and on-demand resource provisioning [4]. More recently, edge and fog computing have extended this model by placing computation closer to data sources, thereby reducing data transmission delay and supporting latency-sensitive applications [5–7]. At the same time, the IoT has introduced large numbers of distributed sensors and actuators that continuously generate real-time data and require timely processing and response [8]. In this continuum-based model, applications can exploit the strengths of different computing layers. Latency-sensitive and context-aware applications, such as autonomous vehicles, healthcare monitoring, industrial automation, and robotics, can benefit from processing near the edge. In contrast, computation-intensive and dataintensive workloads, such as artificial intelligence (AI), machine learning (ML), and large language models (LLMs), often require the high processing capacity and storage resources of cloud data centers [9]. It is noteworthy that, based on model size the inference are also distributed among edge. By dynamically distributing workloads across the continuum, DCCS can improve resource utilization, reduce communication overhead, lower operational cost, and support energy-aware execution [10]. Recently, several architectural advances and algorithmic strategies have emerged for DCCS, including intelligent orchestration [11–14], adaptive task offloading [15–17], resourceaware scheduling [18, 19], service migration [20–24], edge intelligence, and AI-assisted management [25–29]. As these approaches make different assumptions about resources, workloads, mobility, and communication conditions, their performance must be evaluated transparently and consistently to support fair comparison and reproducible conclusions [30]. Therefore, transparent and consistent performance evaluation is increasingly needed. However, existing evaluation practices often focus on isolated dimensions, such as computational performance, network efficiency, energy consumption, reliability, or application-level quality. While these metrics are useful, they do not always capture the cross-layer behavior of DCCS. Performance evaluation is essential for understanding, designing, and improving computing systems, and this importance also extends to DCCS [30]. It supports informed decisions about system architecture, resource provisioning, deployment configuration, and cost-performance trade-offs. It also helps system designers identify bottlenecks, compare alternative configurations, and optimize existing systems according to application requirements [31]. In this sense, performance evaluation provides practical insight into how hardware, software, communication mechanisms, and operational procedures affect the overall behavior of a computing system [32]. However, evaluating DCCS requires a broader perspective than evaluating conventional centralized or homogeneous distributed systems because DCCS consist of distributed,

3

interconnected, and heterogeneous computing nodes spanning cloud, fog, edge, mobile, IoT, and sensor layers. These nodes differ in processing capacity, memory, storage, energy availability, mobility, network connectivity, and failure behavior. Therefore, DCCS performance cannot be fully captured by a single metric or by metrics designed for only one system layer. Instead, benchmarking and performance measurement methods should be selected according to the application domain, deployment scenario, and evaluation objective. The goals of DCCS performance evaluation depend on the system context, application requirements, and deployment objectives [33]. Nevertheless, several evaluation goals are common across DCCS environments, including performance optimization, scalability assessment, Quality of Service (QoS) assurance, bottleneck detection, energy efficiency, cost-effectiveness, reliability, security, and user experience improvement [34, 35]. Performance optimization focuses on reducing latency, improving resource utilization, and distributing workloads efficiently across the continuum. Scalability assessment determines whether the system can handle increasing workloads without unacceptable performance degradation. QoS evaluation verifies whether the system satisfies application-specific requirements such as delay, throughput, availability, and service continuity [36]. Bottleneck detection helps identify performance limitations caused by network latency, bandwidth constraints, overloaded nodes, inefficient algorithms, or resource shortages. Energy and cost evaluation are also critical because DCCS combine low-power IoT devices with energy-intensive cloud and edge infrastructures, which directly affects operational cost and sustainability [37]. Ultimately, performance evaluation helps improve both system efficiency and user satisfaction [38]. While keeping all these complexities in mind, we provide various performance metrics in this paper, and a taxonomy is shown in Figure 1. In short, the contributions of this paper are summarized as follows.

• We present a structured taxonomy of performance metrics for DCCS, considering the heterogeneity of cloud, fog, edge, mobile, IoT, and sensor layers. • We classify performance metrics into computing-, network-, and application- or user-level categories to support systematic evaluation of DCCS behavior. • We provide mathematical formulations for representative metrics, providing precise and comparable performance measurement across different computing configurations. • We discuss metric acquisition requirements, including acquisition scope, acquisition phase, and acquisition method, to clarify how each metric can be measured in practical scenarios. We also provide a discussion on metrics selection criteria while evaluating the performance. • We highlight novel performance metrics, including sustainability, observability, adaptability, energy awareness, and continuum fragmentation, which reflect the changing requirements of modern computing environments. The remaining sections of this paper are organized as follows. In section 2, we provide a detailed DCCS system model, and a taxonomy of performance metrics.

4

Execution and Task Completion Time Throughput

CO2 Emissions

Speedup

Heat Dissipation

Parallel Efficiency

Bottlenecks

Resource Utilization

Measure Observability

Buffer utilization

Adaptivity Quotient Computing-Level Performance Measurement

Maintain Equilibrium Data Locality Index Continuum Fragmentation Index Migration Stability Index

Novel Metric for Changing DCC demands

Concurrency

SLO Violation Recovery Time

Load Balancing Task Completion Ratio

Water Usage Efficiency

Cost Efficiency

Data Freshness or Age of Information Trustworthiness Score

Network Latency

Cate.

Jitter

Task Success Metrics

Bandwidth Utilization

Cost

Packet Loss Rate

Time and Space Complexity

Packet Delivery Rate

Accuracy

Network Throughput

Availability

Efficiency Metrics

Scalability Energy Consumption and Efficiency

Carbon Efficiency per Useful Task

Error Rate

Reliability Elasticity

Adaptation Cost Efficiency

SLO and SLA Compliance

Availability

Goodput

Application or User-Level Performance Measurement

Response Time Network-Level Performance Measurement

User Satisfaction Metrics Learnability Metrics

Service Time Queueing Delay Network Congestion Level Network Availability

Flexibility Application Portability

Network Reliability

Application Robustness

Handover Delay Communication Energy Consumption Connection Density Path Stretch Network Cost

Fig. 1: A Taxonomy of Performance Metrics for the DCCS

In section 3, we provide various criteria to be followed to consider particular performance metrics and feasibility analysis. Section 4 discusses various computing-level performance metrics and their mathematical formulae. Section 5 provides a variety of network-level performance metrics and mathematical formulae. In Section 6, we discuss various performance metrics at application or user-level along with their mathematical formulae. Section 7 introduced several novel performance metrics need for the changing computational demands. Finally, we conclude our paper with a future scope in Section 8.

2 System Model This section provides a detailed system model of the computing continuum through mathematical notations. In addition, a graphical representation is also provided in Figure 2. The most frequently used notations are summarized using Table 1. 5

DCCS (S ) consists of n devices, including a set of cloud/data centers C = {C1 , C2 , . . . , Cc }, where c = |C|, a set of fog nodes F = {F1 , F2 , . . . , Ff }, where f = |F|, a set of edge nodes E = {E1 , E2 , . . . , Ee }, where e = |E|, a set of mobile devices M = {M1 , M2 , . . . , Mm }, where m = |M|, a set of IoT devices Γ = {I1 , I2 , . . . , Iι }, where ι = |Γ|, and a set of sensor nodes Ψ = {ψ1 , ψ2 , . . . , ψς }, where ς = |Ψ|. We assume that Ψ are data producers and they are not capable of computing any data. So, they transmit their data to the nearest base station, i.e., Γ, M, or E using pointto-point communication mechanism through Bluetooth Low Energy (BLE), Zigbee, Cellular, or Wi-Fi communication channels [39]. Usually, Ψ are operated using a limited powered battery to supply energy [40]. The Γ have higher computing power than Ψ, and connected with other devices (Γ, M, E , C , or F ) using Internet, in contrast, Ψ usually uses Intranet as discussed before. These nodes are also data producers. In general, we assume the number of SNs is higher than IoT in S i.e., ι ≤ ς . Γ use either low power battery or a regular power supply to input the energy depending on the application. For example, applications like smart buildings can be supplied directly with electricity, whereas smart agriculture applications will require batteries. Edge devices (E ) are closer to the data producer (For example, Gateways, Routers, or Switches) and provide computing services with low latency. Depending on the application, sometimes Γ acts as edge devices. The E perform various functions, including routing, transmission, processing, filtering, monitoring, translation, and storage of processed data. These are also associated with higher memory and computing powers than Γ. Due to this, the energy consumption of E is higher than Γ and Ψ. These devices also can operate both battery or regular power supply depending on application, and location of the device deployment. Usually, DCCS use less E than Γ, i.e., e ≤ ι to minimize overall cost of S . Fog nodes (F ) are placed between edge and cloud or data centers to make the computation close to the data source. In some applications, fog nodes have higher memory or computing power than edge nodes, and in some other cases, both are similar [41]. F do not produce any data, whereas they mainly perform computing tasks and store or revert the decisions on processed data. Since the energy need of F

Table 1: Frequently used notations. Notation S C F E M Γ Ψ N N all Vi Vir Cij T Ti Tf xij di τi µj ∆t

Meaning DCCS system Set of cloud/data centers Set of fog nodes Set of edge nodes Set of mobile devices Set of IoT devices Set of sensor nodes Set of computing-capable nodes Set of all devices in S Set of VMs in cloud/data center Ci VM r in cloud/data center Ci Direct connectivity indicator between nodes i and j Set of tasks Task i Set of failed tasks Task assignment indicator for task i on node j Input data size of task i Arrival time of task i Processing capacity of node j Observation window

6

Notation n c f e m ι ς ζ ρ ki Ei = 0 L q Tc Tδc ωi ri δi Bij [t0 , t1 ]

Meaning Total number of devices in S Number of cloud/data centers, c = |C| Number of fog nodes, f = |F | Number of edge nodes, e = |E| Number of mobile devices, m = |M| Number of IoT devices, ι = |Γ| Number of sensor nodes, ς = |Ψ| Number of computing-capable nodes, ζ = |N | Number of data-producing nodes Number of VMs in Ci , ki = |Vi | Operational state of node j Set of communication links Number of generated tasks, q = |T | Set of completed tasks Set of tasks completed within deadlines Computational workload of task i Output/result size of task i Deadline of task i Available bandwidth between nodes i and j Start and end times of ∆t

Cloud Domain

Services Networking Servers

Cloud

Data Centers

Fog

Distributed Edge

NPU

NPU

NPU

IoT Domain

Distributed Computing Continuum Fog Domain Edge Domain

Storage

Internet of Things

Fig. 2: The general architectural view of Distributed Computing Continuum and its components [30]

is higher than Γ, connecting with a regular power supply is a suitable option. Setup F are more expensive than edge devices, but lower than cloud or data centers. So, in S maintaining (f < e) or (f < ι). E and F are stationary, and their locations are fixed in S . Mobile devices (M) are changing their geographical location timely due to their mobility feature. Most of the applications, the configurations of M are similar to either E or F [42]. However, M can be data producers in some cases, for example, mobile phones or autonomous vehicles. Since M are moving, it is not possible to provide a fixed electricity supply, and they are possibly operating through a battery or wireless energy transmissions [43]. The communication with the Γ, and Ψ is also complex [44], but the services to these devices can be performed quickly with a minimum number of devices. However, the number of M always to be minimal compared to E , Γ, and Ψ to minimize overall cost of S . Cloud (C ) provides on-demand computational or storage resources, and their resources are unlimited. Since C is unlimited resources, it is not necessary to maintain a huge number of cloud centers, i.e., c = 1. The c > 1, only for 7

the case of huge amount of data (such as Generative AI [45, 46] or Large Language Models [47, 48]) which is not possible to manage at one machine or store the data in multiple replications. Due to high computing power, and maintaining high availability, it is necessary to supply continuous energy through a regular power supply. Each Ci further split in to k virtual machines (VMs) (Vi = {Vi1 , Vi2 , ...., Vik }, ∀ (1 ≤ i ≤ c)). As discussed above, all devices in S have no computational power (For example, Ψ), the computing nodes are assumed as ζ , which is treated as ζ = (c + f + e + m + ι). The total number of data producers is ρ = (ς + ι + e + m), whereas E , and M properties may vary from application to application. To optimize the overall S cost, the ζ is optimized according to (c < f < e ≤ m ≤ ι) and (ζ < ρ). Each computing node in S can be one of several states such as active or operational (0), inactive or fail (1). For example, Ei = 0 means the edge node i∀i ∈ (1, e) is active or operational. Similarly, Vik = 1 means the VM k of cloud Ci is inactive or failed. (Note: Depends on the need, these can be further split individual to know the accurate state of any computing node. This means not all active nodes are operational and not all inactive nodes are failed. In this case, each state is assigned using different numbers from 0 to 3.) It is also necessary to identify whether a node (within the same class or a different class) is able to exchange information or communicate with each other. We can maintain a connection matrix Cij = 0, 1, where (i, j ∈ n) and (i ̸= j ), here (n = c + f + e + m + ι + ς ). For example, Cij = 0 means nodes i and j cannot directly communicate, whereas Cij = 1 means they can directly communicate without using an intermediate node.

3 Metrics Selection Criteria and Feasibility Analysis In general, evaluating all performance metrics simultaneously is practically challenging due to monitoring overhead and system complexity. Also, a single metric is usually not sufficient to describe the behavior of the whole continuum. Therefore, when selecting metrics, system architects must consider how they affect the overall complexity: the more parts of the system a metric spans and the more experimental its nature, the more difficult it becomes to implement. Further, the selected metrics should depend on the purpose of the evaluation. For example, an IoT-based health monitoring application may prioritize latency, reliability, availability, and energy consumption, while an industrial automation system may focus on response time, fault tolerance, synchronization accuracy, and network stability. Similarly, a large-scale smart city application may require metrics related to scalability, throughput, resource utilization, and data processing efficiency. Therefore, metric selection must be guided by the operational goals of the DCC system rather than by the availability of metrics alone. Further, we also provide metric wide feasibility within this section.

3.1 Metrics Selection Criteria The first and most important criterion is relevance. A metric should be directly related to the objectives of the DCC system under study. Since DCC environments distribute tasks across IoT, edge, fog, and cloud resources, the metric should capture the effect of this distribution on system performance. For instance, latency is relevant when 8

the objective is to support real-time decision-making at the edge, while energy consumption is relevant when the system includes battery-powered IoT devices. Resource utilization is important when evaluating how efficiently workloads are allocated across edge and cloud nodes. A metric that does not reflect the main objective of the system may lead to incomplete or misleading conclusions. Another essential property is sensitivity. A suitable metric should be able to detect small but meaningful changes in system behavior. In DCC systems, performance may change because of variations in network conditions, workload intensity, node mobility, resource availability, task placement, or data volume. A sensitive metric should reflect these changes clearly. For example, if computation is moved from the cloud to an edge server, the response time metric should show whether the change reduces delay. Similarly, if the number of connected IoT devices increases, scalability and throughput metrics should reveal whether the system can still maintain acceptable performance. The selected metric should also be consistent, means that the metric must have the same definition, unit, and measurement method across different experiments, configurations, and DCC layers. This is particularly important because DCC systems contain heterogeneous resources with different processing capacities, communication technologies, and energy profiles. For example, comparing latency between an IoTto-edge path and an IoT-to-cloud path is only meaningful when latency is measured in the same way in both cases. Without consistency, it becomes difficult to compare different architectures, algorithms, or deployment strategies fairly. A performance metric must also be repeatable, means that the metric can be measured using the same procedure whenever the experiment is repeated under the same conditions. This property is necessary to ensure that the evaluation results are reliable. In DCC environments, repeatability can be challenging because of dynamic factors such as changing network bandwidth, device mobility, workload fluctuations, and node failures. Therefore, the measurement process should be clearly defined. The experiment should specify where the metric is measured, how often it is measured, what tools are used, and which system conditions are controlled. The metric should be easy to understand and easy to use. A useful metric should have a clear meaning and should be simple enough to interpret by researchers, developers, and system operators. For example, response time, packet delivery ratio, CPU utilization, and energy consumption are easier to understand than complex composite indicators with unclear definitions. Simplicity is important because DCC systems are already complex. If the metric itself is difficult to interpret, it may reduce the usefulness of the evaluation. However, simplicity should not come at the cost of accuracy. The metric should remain meaningful and should still represent the behavior of the system correctly. A good metric should provide sufficient coverage of the DCC behavior. Since the DCC spans multiple layers, the selected metrics should capture performance from different perspectives. These perspectives may include communication performance, computation performance, resource efficiency, reliability, scalability, and energy efficiency. For example, communication-related metrics may include latency, bandwidth usage, jitter, and packet loss. Computation-related metrics may include task execution time, processing delay, and workload distribution. Resource-related metrics

9

may include CPU utilization, memory usage, storage usage, and network utilization. Reliability-related metrics may include failure rate, availability, and service continuity. Energy-related metrics may include device energy consumption, node lifetime, and energy per processed task. The metric should be as independent as possible from external influences that are not part of the system being evaluated. In practice, DCC performance may be affected by background traffic, hardware differences, environmental conditions, wireless interference, simulation parameters, or measurement noise. A good metric should minimize the impact of such external factors, or these factors should be clearly controlled and reported. For example, when comparing two task scheduling algorithms, both algorithms should be evaluated under the same workload, network conditions, and resource constraints. Otherwise, the observed difference may come from the environment rather than from the algorithm itself. The selected metrics should also support comparability. One of the main purposes of performance evaluation is to compare different DCC architectures, algorithms, configurations, or deployment strategies. Therefore, metrics should be chosen in a way that enables fair comparison. For example, when comparing cloud-only processing with edge-assisted processing, the evaluation may include response time, bandwidth consumption, energy usage, task completion rate, and cost. These metrics help show not only which approach performs better, but also why it performs better.

3.2 Feasibility Analysis This section propose analysis aiming to provide an objective assessment of metric feasibility. Instead of classifying metrics according to subjective criteria such as whether they are easy or difficult to obtain, we characterize their feasibility through a set of data acquisition dimensions. These dimensions provide a structured way to analyze the effort required to obtain each metric, since collecting information from multiple entities or requiring additional mechanisms for data collection increases the complexity of the acquisition process. The analysis considers the following data acquisition dimensions: 1. Scope (the where): defines the minimum source of information required to obtain a metric. The considered options are Single-Node , Multi-Node , Full System , and Full App , depending on whether the required information can be obtained from a single computational node, multiple interacting nodes, the entire DCCS, or all components belonging to a specific application. 2. Phase (the when): defines the context in which the required data is collected. The considered options are Operational and Experimental . The former refers to data collected during normal system operation, while the latter refers to data collected through controlled evaluation scenarios. 3. Method (the how): Defines how the required data is collected, that is, the degree of modification or integration required in the system to enable data collection. The options are classified as follows: 10

• Standard Telemetry : No modifications are needed; it uses the built-in, out-ofthe-box telemetry mechanisms already available in the system. • Custom Instrumentation : Requires modifying the application by adding custom code or specific configurations to extract tailored internal data. • Experimental Instrumentation : Requires integrating non-conventional components, such as external hardware sensors, unestablished frameworks, or novel measurement procedures. These dimensions are used to analyze the feasibility of acquiring each metric. A broader scope increases the difficulty of collecting and correlating data from multiple entities. The phase affects feasibility because metrics requiring experimental scenarios may need controlled deployments, specific configurations, or comparisons between different executions instead of relying on normal system operation. The method impacts feasibility by increasing the required level of technical knowledge and the number of modifications needed to obtain the data.

4 Computing-level Performance Measurement Computing-level performance measurement evaluates how efficiently the computing resources of a DCCS are used to execute tasks under dynamic workload, mobility, heterogeneity, and resource constraints. In the considered system model, the computing-capable devices are represented by ζ = (c + f + e + m + ι), where cloud/data centers, fog nodes, edge nodes, mobile devices, and IoT devices are assumed to have computing capability, while sensor nodes Ψ are mainly considered data producers. Therefore, the computing-level performance of S depends not only on the amount of available resources, but also on how these resources are used, shared, scaled, balanced, and maintained over time. Table 2 summarizes the acquisition requirements associated with each metric through three dimensions: minimal acquisition scope, acquisition phase, and acquisition method. Let N denote the set of computing-capable nodes in S , such that

N = C ∪ F ∪ E ∪ M ∪ Γ,

(1)

where |N | = ζ . Let T = {T1 , T2 , . . . , Tq } denote the set of computational tasks generated by the data producers in S during an observation window ∆t = [t0 , t1 ]. Each task Tx ∈ T can be represented as

Tx = ⟨ωx , dx , τx , δx ⟩,

(2)

where ωx denotes the computational workload, dx denotes the input data size, τx denotes the task arrival time, and δx denotes the task deadline. A task Tx may be executed on one or more computing nodes depending on the scheduling, offloading, 11

Table 2: Acquisition requirements for computation-oriented metrics. Metric Execution Time Task Completion Time Throughput Speedup Parallel Efficiency Resource Utilization Buffer Utilization Availability Reliability Scalability Elasticity Energy Consumption Energy Efficiency Concurrency Load Balancing Task Completion Ratio Cost Efficiency Comp. Cont. Efficiency

Scope Single-Node Single-Node Single-Node Multi-Node Multi-Node Single-Node Single-Node Single-Node Single-Node Multi-Node Multi-Node Single-Node Single-Node Single-Node Multi-Node Single-Node Single-Node Multi-Node

Phase Operational Operational Operational Experimental Experimental Operational Operational Operational Operational Experimental Experimental Operational Experimental Operational Operational Operational Experimental* Experimental

Method Standard Telemetry Standard Telemetry Custom Instrumentation* Standard Telemetry Standard Telemetry Standard Telemetry Standard Telemetry Standard Telemetry Standard Telemetry Custom Instrumentation* Experimental Instrumentation Experimental Instrumentation Experimental Instrumentation Standard Telemetry Standard Telemetry Custom Instrumentation* Experimental Instrumentation Experimental Instrumentation

and resource allocation mechanism. Let xij be a binary assignment variable, where

( xij =

1, 0,

if task Ti is assigned to computing node j, otherwise.

(3)

The following subsections define computing-level performance metrics suitable for DCCS.

4.1 Execution and Task Completion Time Execution time is one of the most fundamental computing-level performance metrics. Let Ti be a task assigned to computing node j ∈ N . The execution time can be expressed as ωi ETij = , (4) µj where ωi is the computational workload of task Ti and µj is the processing capacity of node j . In heterogeneous DCCS, µj varies significantly across IoT, edge, fog, mobile, and cloud nodes. Task Completion Time (TCT) measures the total time required to complete a task, including queueing, communication, execution, and result delivery delays. The total response time of task Ti can be represented as

T CTi = QTi + CTi + ETi + OTi ,

(5)

where QTi is the queueing time, CTi is the communication time, ETi is the execution time, and OTi is the output transmission or result-return time. If task Ti is executed 12

on node j , then

di ωi ri + + , (6) Bsj µj Bjd where Bsj is the bandwidth between the source node and node j , ri is the result size, and Bjd is the bandwidth between node j and the destination node. The average response time of all completed tasks in ∆t is given by T CTi = QTi +

T CT =

1 X RTi , |T c | c

(7)

Ti ∈T

where T c is the set of completed tasks. As summarized in Table 2, the Execution Time metric measures the time required to complete a task. The minimal acquisition scope is Single-Node because a task execution can be completed within a single computational node. The acquisition occurs during the Operational phase in order to detect execution delays and performance degradation during task execution. The acquisition method is Standard Telemetry because trace and span durations are already exposed by standard instrumentation frameworks such as OpenTelemetry. Similarly, in T CT , the minimal acquisition scope is Single-Node because the total elapsed time between task submission and completion can be measured locally by the requesting node, regardless of where the task is executed. The acquisition occurs during the Operational phase in order to detect performance degradation not only at the node level but also along the communication path between services. The acquisition method is Standard Telemetry because full request durations can be obtained from traces exposed by standard instrumentation frameworks such as OpenTelemetry.

4.2 Throughput Throughput [49] measures the number of tasks successfully completed per unit time. In DCCS, throughput can be measured at the node level, layer level, or system level. The system-level throughput during ∆t is defined as

T HS =

|T c | , ∆t

(8)

where |T c | is the number of completed tasks. The node-level throughput of node j is

T Hj =

|Tjc | , ∆t

(9)

where Tjc is the set of tasks completed by node j . Layer-wise throughput can be computed as

T HL =

1 X c |Tj |, ∆t j∈L

13

(10)

where L ∈ {C, F, E, M, Γ}. This formulation helps identify which layer contributes most to task execution. Further, the minimal acquisition scope is Single-Node because it can be obtained at the individual node level, although it can also apply to multiple nodes or layers. The acquisition occurs during the Operational phase in order to detect performance degradation. The acquisition method is Custom Instrumentation because the application must define what constitutes a successfully completed task (e.g., within a given execution time or meeting a specific quality criterion). However, if task completion is represented by a simple event already exposed through standard metrics, Standard Telemetry is sufficient.

4.3 Speedup Speedup measures how much faster a task or workload is executed using a distributed or parallel computing configuration compared with a baseline configuration [50]. For a workload W , speedup is defined as

Sp =

ET1 , ETp

(11)

where ET1 is the execution time using one baseline computing node and ETp is the execution time using p computing nodes. For DCCS, if a task set T is executed using ζ computing nodes, the system-level speedup can be expressed as Tsingle Sζ = , (12) Tdccs where Tsingle is the execution time using a single reference node, and Tdccs is the execution time using the available computing continuum. Amdahl’s law can be used to estimate the theoretical speedup when a fraction α of the workload can be parallelized [51]. It is given by

SAmdahl (ζ ) =

1 , (1 − α) + αζ

(13)

where 0 ≤ α ≤ 1. This formulation is suitable when the problem size is fixed. For scalable workloads, Gustafson’s law can be used [52]. It is expressed as

SGustafson (ζ ) = (1 − α) + αζ.

(14)

This formulation is more suitable when the workload size increases with the available computing resources. In DCCS, due to communication delay and synchronization overhead, practical speedup is usually lower than theoretical speedup. Therefore, an overhead-aware speedup can be defined as

SDCCS =

Tsingle , Tcompute + Tcomm + Tsync + Tmigration 14

(15)

where Tcompute is the actual computation time, Tcomm is communication time, Tsync is synchronization time, and Tmigration is task or data migration time. From Table 2, the minimal acquisition scope is Multi-Node because it compares performance data across different deployment configurations involving multiple computational nodes. The acquisition occurs during the Experimental phase because the metric is primarily used to compare deployment configurations in order to identify the most efficient system design or resource allocation. Although it could be evaluated during operation if a baseline is preconfigured, continuous runtime comparison between configurations is generally impractical. The acquisition method is Standard Telemetry because the metric is calculated from execution times, which, as previously explained, can be readily obtained through standard instrumentation.

4.4 Parallel Efficiency The Parallel Efficiency metric measures how close the system’s speedup is to the ideal theoretical linear acceleration expected from the number of allocated computing nodes. It is defined as Sζ . (16) P Eζ = ζ The value of P Eζ lies in the range (0, 1] for most practical systems. A value close to 1 indicates near-ideal resource usage, while a lower value indicates communication overhead, synchronization delay, load imbalance, or resource underutilization. For heterogeneous DCCS, a weighted parallel efficiency can be defined as

Sζ

WPE = P

j∈N wj

,

(17)

where wj represents the normalized computing capacity of node j . This is more suitable than simple node counting when the system contains heterogeneous devices such as IoT, edge, fog, mobile, and cloud nodes. Further, the acquisition minimal scope is Multi-Node because P Eζ requires performance data across multiple distributed resources and configurations to calculate the resulting resource usage efficiency. The acquisition occurs during the Experimental phase because it depends on the speedup obtained from comparing different deployment configurations and is therefore primarily intended for design-time performance analysis rather than continuous operational monitoring. The acquisition method is Standard Telemetry because it is derived from the speedup and the number of allocated computing nodes, both of which are obtained from data already available through standard telemetry.

4.5 Resource Utilization Resource utilization measures how much of the available computing resources (such as CPU, memory, storage, etc.,) are actually used during a given observation window (e.g., [53, 54]). The CPU utilization of node j can be defined as

Ujcpu =

Tjbusy , ∆t

15

(18)

where Tjbusy is the total time during which the CPU of node j is busy. The average CPU utilization of the whole DCCS is

UScpu =

1 X cpu Uj . ζ

(19)

j∈N

If the computing nodes have different capacities, weighted CPU utilization can be defined as P cpu j∈N µj Uj cpu . (20) W US = P j∈N µj Memory utilization of node j is defined as

Ujmem =

Mjused Mjtotal

,

(21)

where Mjused is the used memory and Mjtotal is the total available memory. Storage utilization is defined as

Ujsto =

Sjused Sjtotal

.

(22)

A composite resource utilization metric can be defined as

Ujres = ya1 Ujcpu + ya2 Ujmem + ya3 Ujsto + ya4 Ujnet ,

(23)

where Ujnet is network utilization and ya1 + ya2 + ya3 + ya4 = 1. The weights can be adjusted according to the application requirements. The acquisition minimal scope is Single-Node because Ujres metrics are isolated and measured directly within each independent computing node. The acquisition occurs during the Operational phase in order to monitor the operational state of the nodes and detect potential resource exhaustion in real time. The acquisition method is Standard Telemetry because infrastructure indicators like CPU load and memory usage are natively exposed by the operating systems (OS).

4.6 Buffer Utilization Buffer utilization is important for DCCS because data may be temporarily stored at IoT, edge, fog, or cloud nodes before processing. Let Bjused (t) be the used buffer size of node j at time t, and Bjmax be the maximum buffer capacity [55]. The instantaneous buffer utilization is Bjused (t) . (24) Ujbuf (t) = Bjmax 16

The average buffer utilization during ∆t is buf Uj =

1 ∆t

Z t1 t0

Bjused (t) dt. Bjmax

(25)

In discrete monitoring intervals, this can be written as buf

Uj

=

H 1 X Bjused (h) , H Bjmax

(26)

h=1

where H is the number of monitoring samples. A high buffer utilization may indicate efficient buffer usage, but very high values can lead to congestion and packet/task dropping. Therefore, buffer overflow probability can be defined as Njdrop Pjoverf low = , (27) Njarr where Njdrop is the number of dropped tasks or packets and Njarr is the total number of arrivals at node j . The Ujbuf (t) metric measures the proportion of the available buffer capacity currently in use. Since a buffer can be considered a computational resource managed by a node, its acquisition requirements are equivalent to those of the Ujres metric: the minimal acquisition scope is Single-Node , the acquisition occurs during the Operational phase, and the acquisition method is Standard Telemetry .

4.7 Availability Availability measures the probability that a computing node or the whole DCCS is operational at a given time. For node j , availability can be expressed using mean time to failure (MTTF) and mean time to repair (MTTR) as

Aj =

M T T Fj . M T T Fj + M T T Rj

(28)

If the failure and repair rates are represented as λj and µrj , respectively, then availability can also be written as

Aj =

µrj . λj + µrj

(29)

The average availability of the DCCS is

AS =

1 X Aj . ζ j∈N

17

(30)

For capacity-aware availability, the formulation can be extended as P j∈N µj Aj W AS = P . j∈N µj

(31)

If the DCCS is considered operational only when at least one cloud, one fog/edge, and one data-producing layer are available, system availability can be represented as

AS = AC · [1 − (1 − AF )(1 − AE )] · Aρ ,

(32)

where AC , AF , AE , and Aρ denote the availability of the cloud, fog, edge, and dataproducing components, respectively. The acquisition minimal scope is Single-Node because availability can be estimated independently for each computing node. The acquisition occurs during the Operational phase because Aj is useful for detecting nodes that experience frequent outages in production. Note that meaningful availability estimates require sufficient historical operational data to produce reliable results. The acquisition method is Standard Telemetry because operational status information can be collected through standard monitoring mechanisms, such as heartbeat signals, which provide the data required for availability estimation.

4.8 Reliability Reliability measures the probability that a computing node or system operates without failure for a given time duration. If node j has a constant failure rate λj , its reliability over time t is Rj (t) = e−λj t . (33) The reliability of a task execution path Pi can be defined as

R(Pi ) =

Y

Rj (t),

(34)

j∈Pi

where Pi includes the computing and communication nodes involved in executing task Ti . For replicated task execution across multiple nodes, reliability can be improved as

Rrep =1− i

Y

(1 − Rj (t)) ,

(35)

j∈Ri

where Ri is the set of nodes selected for replicated execution of task Ti . The acquisition minimal scope is Single-Node because reliability is estimated independently for each computing node based on its failure history. As shown in Table 2, the acquisition occurs during the Operational phase because reliability helps identify nodes that are prone to failures during production. Note that, besides requiring historical failure data, the metric must be evaluated over a predefined time interval. Therefore, realtime reliability monitoring is only practical when this temporal parameter is defined in advance. The acquisition method is Standard Telemetry because failure events and 18

operational time can be collected through standard monitoring mechanisms, such as heartbeat signals, and later used to compute reliability estimates.

4.9 Scalability Scalability measures the ability of the DCCS to maintain acceptable performance when workload or system size increases. It can be measured through speedup, scaleup, sizeup, and resource expansion efficiency. This performance metric is generally used in several computing architectures in the literature including, cloud, or IoT. However, this is very relevant in the context of DCCS as well. The throughput-based scalability from configuration a to configuration b can be defined as T Hb Ra SCT H = · , (36) T Ha Rb where T Ha and T Hb are throughputs under configurations a and b, and Ra and Rb are the amount of provisioned resources. A scalability value close to 1 indicates near-linear scalability. A value lower than 1 indicates that increasing resources does not proportionally improve throughput. The workload scalability can be represented as

SCW =

Wb /Wa , RTb /RTa

(37)

where Wa and Wb are workload intensities, while RTa and RTb are the corresponding response times. If the workload increases but response time remains stable, the system is considered scalable. A deadline-aware scalability metric can be defined as

SCδ =

|Tδc | , |T |

(38)

where Tδc is the set of tasks completed within their deadlines. This is useful for real-time DCCS applications. The minimal acquisition scope is Multi-Node because scalability is evaluated by comparing throughput across multiple deployment configurations. The acquisition occurs during the Experimental phase because scalability is primarily assessed through controlled experiments that compare different configurations in order to identify the most effective system design. The acquisition method is Custom Instrumentation because, although resource metrics are available through Standard Telemetry , throughput may require custom instrumentation, as previously explained.

4.10 Elasticity The Elasticity metric measures the system’s capacity to adapt its resource provisioning dynamically to match varying workload demands over time [56, 57]. Unlike 19

scalability, elasticity includes the temporal behavior of resource provisioning and deprovisioning [56, 58–60]. This performance metric extended according to the recent advancements in computing paradigms under novel performance metrics in section 7.6. Let D(t) denote the resource demand at time t, and P (t) denote the provisioned resources. Resource provisioning accuracy can be measured as

EA(t) = 1 −

|P (t) − D(t)| . D(t)

(39)

The average elasticity accuracy over ∆t is H

EA = 1 −

1 X |P (h) − D(h)| . H D(h)

(40)

h=1

Over-provisioning and under-provisioning can be measured separately as

  H 1 X P (h) − D(h) OP = max 0, , H D(h)

(41)

  H 1 X D(h) − P (h) UP = max 0, . H D(h)

(42)

h=1

and

h=1

The elasticity reaction time is defined as

ERT = tstable − tchange ,

(43)

where tchange is the time when workload changes and tstable is the time when the system reaches a stable resource configuration. A combined elasticity score can be defined as

ES = η1 EA + η2 (1 − OP ) + η3 (1 − U P ) + η4

1 , 1 + ERT

(44)

where η1 + η2 + η3 + η4 = 1. The acquisition minimal scope is Multi-Node because it requires evaluating changes in resource configurations across multiple distributed nodes. The acquisition phase is Experimental because analyzing the speed and precision of provisioning adaptation requires controlled stress or workload scaling experiments. The acquisition method is Experimental Instrumentation because, although provisioned resources are readily available through standard telemetry, estimating the actual resource demand often requires experimental models or external evaluation procedures that are not part of conventional monitoring.

4.11 Energy Consumption and Efficiency Energy consumption and energy efficiency [61–64] are critical performance metrics in several computing paradigms, and DCCS is not exceptional because many IoT, 20

sensor, edge, and mobile devices are battery-powered [65] or energy dependent. It is noteworthy that, several works in the literature oscillate among measuring energy consumption or energy efficiency [66]. The energy consumed by node j during ∆t can be computed as Z t1

Ej =

Pj (t)dt,

(45)

t0

where Pj (t) is the power consumption of node j at time t. In discrete form, H X Ej = Pj (h)∆h.

(46)

h=1

The total energy consumption of the DCCS is

ES =

X

Ej .

(47)

j∈N

The energy consumed for task Ti executed on node j can be approximated as

Eij = Pjcpu ETij + Pjcomm CTij + Pjidle ITij ,

(48)

where Pjcpu , Pjcomm , and Pjidle denote computation, communication, and idle power consumption, respectively. The minimal acquisition scope is Single-Node because energy consumption can be measured independently for each computing node. The acquisition occurs during the Operational phase because monitoring energy consumption is critical for battery-powered DCCS nodes, where energy availability directly limits operating time. The acquisition method is Experimental Instrumentation because accurate energy measurements typically require hardware energy sensors or platform-specific monitoring interfaces. When direct measurements are unavailable, such as in cloud environments, a rough estimation can be obtained from resource utilization and the processor’s TDP, as proposed in [67]. Energy efficiency measures the amount of useful work completed per unit energy. It can be defined as |T c | EES = , (49) ES where |T c | is the number of completed tasks. If workload size is considered, energy efficiency can be expressed as P c ωi EESwork = Ti ∈T . (50) ES For deadline-sensitive applications, useful energy efficiency can be defined as

EESδ =

|Tδc | , ES

where Tδc denotes the set of tasks completed within their deadlines. 21

(51)

Energy-delay product (EDP) can also be used to jointly evaluate energy and delay:

EDPi = Ei × RTi .

(52)

A lower EDP indicates better energy-delay performance. The minimal acquisition scope is Single-Node because the completed workload and the corresponding energy consumption can be measured for an individual computing node. The acquisition occurs during the Experimental phase because energy efficiency is primarily used to evaluate and compare system designs under controlled conditions rather than to support operational decisions, although it can also be computed during operation when energy consumption measurements are available. The acquisition method is Experimental Instrumentation because it inherits the acquisition requirements of the Energy Consumption metric, previously discussed.

4.12 Concurrency Concurrency measures the ability of the computer systems to handle multiple tasks simultaneously [68–70]. In DCCS, let Q(t) be the number of tasks being processed or waiting in the system at time t. The average concurrency level is

CL =

1 ∆t

Z t1 Q(t)dt.

(53)

t0

Using Little’s law, the average number of tasks in the system can be related to throughput and response time as Q = ΛW, (54) where Λ is the task arrival rate and W is the average time a task spends in the system. For DCCS, this can be written as

CLS = ΛS RT ,

(55)

where ΛS is the system-level task arrival rate and RT is the average response time. The maximum concurrency capacity can be estimated as

CCS =

X

qj ,

(56)

j∈N

where qj is the maximum number of tasks that node j can execute concurrently. The concurrency utilization is then

UScon =

CLS . CCS

(57)

The minimal acquisition scope is Single-Node because the number of concurrent tasks can be measured independently for each computing node and later aggregated to characterize the entire system. The acquisition occurs during the Operational phase 22

because monitoring concurrency helps identify workload saturation during system operation. The acquisition method is Standard Telemetry because the number of concurrently executing or queued tasks can typically be obtained from existing runtime or infrastructure telemetry.

4.13 Load Balancing Load balancing measures how evenly tasks or workloads are distributed across computing nodes [71]. Let Loadj denote the load assigned to node j . This load can represent CPU usage, number of tasks, queue length, or workload size. The average load is

Load =

1 X Loadj . ζ

(58)

j∈N

The load imbalance degree can be defined as

q P 1

2 j∈N (Loadj − Load)

ζ

LID =

Load

.

(59)

A lower LID indicates better load balancing. Jain’s fairness index can also be used to measure load distribution fairness [72]. It is defined as P 2 Load j j∈N P JF I = . (60) ζ j∈N Load2j The value of JF I lies in (0, 1], where 1 indicates perfectly balanced load distribution. For heterogeneous DCCS, load should be normalized by node capacity. Therefore, normalized load can be defined as

N Loadj =

Loadj . µj

(61)

The normalized load imbalance degree is

q P 1 N LID =

ζ

2 j∈N (N Loadj − N Load)

N Load

,

(62)

where N Load is the average normalized load. As shown in Table 2, The minimal acquisition scope is Multi-Node because load balancing is evaluated by comparing the load assigned to multiple computing nodes. The acquisition occurs during the Operational phase because it enables the detection of workload imbalances during system operation. The acquisition method is Standard Telemetry because node load indicators, such as resource utilization, queue length, or task count, are typically available through existing instrumentation. 23

4.14 Task Completion Ratio Task completion ratio measures the fraction of generated tasks that are successfully completed or it measures the proportion of successfully completed tasks with respect to the total number of submitted tasks. It is defined as

T CR =

|T c | . |T |

(63)

For deadline-constrained applications, deadline-aware task completion ratio is more suitable: |T c | (64) DT CR = δ . |T | If failed tasks are represented by T f , then task failure ratio is

|T f | . |T |

TFR =

(65)

The minimal acquisition scope is Single-Node because task submissions and completions can be measured independently for each computing node. The acquisition occurs during the Operational phase because monitoring the task completion ratio helps detect execution failures or service degradation during system operation. The acquisition method is Custom Instrumentation because the application must define what constitutes a successfully completed task, as previously discussed for the Throughput metric.

4.15 Cost Efficiency This metric measures the amount of useful work completed with respect to the operational cost of the computing resources. Although cost is not purely a computing-level metric, it is strongly related to computing performance in DCCS because cloud, fog, edge, and mobile resources have different deployment and operational costs. Let Costj denote the operational cost of using node j during ∆t. The total system cost is

CostS =

X

Costj .

(66)

j∈N

The cost per completed task is

CP T =

CostS . |T c |

(67)

The cost-performance efficiency can be defined as

CP E =

T HS . CostS

24

(68)

A combined energy-cost efficiency metric can be expressed as

ECE =

|Tδc | , w1 ES + w2 CostS

(69)

where w1 and w2 are weighting factors. The minimal acquisition scope is Single-Node because the operational cost can be estimated independently for each computing node and later aggregated at the system level if needed. The acquisition occurs during the Experimental * phase because cost efficiency is primarily used to evaluate deployment strategies. However, it can also be computed during the Operational phase if cost estimation is continuously available with acceptable overhead. The acquisition method is Experimental Instrumentation because estimating operational cost requires integrating cost models or pricing information, for which no standard telemetry mechanism currently exists.

5 Network-level Performance Measurement Network-level performance measurement evaluates the efficiency, reliability, and quality of communication among heterogeneous devices in a DCCS. In contrast to computing-level performance, which focuses on task execution and resource usage, network-level performance focuses on data transmission among sensor nodes, IoT devices, mobile devices, edge nodes, fog nodes, and cloud/data centers. Since DCCS involves geographically distributed, mobile, and resource-constrained components (i.e., whose intelligent management increasingly relies on AI/ML-driven orchestration across the continuum [73]) network-level metrics are essential for measuring latency, bandwidth usage, packet delivery, throughput, service delay, communication reliability, and network availability. Table 3 summarizes the acquisition requirements associated with each network-level metric. Let N all denote the set of all devices in S , including computing and non-computing devices: N all = C ∪ F ∪ E ∪ M ∪ Γ ∪ Ψ, (70) where |N all | = n. The connection between any two devices i, j ∈ N all is represented using the connection matrix Cij :

( Cij =

1, 0,

if nodes i and j can communicate directly, otherwise.

(71)

Let L denote the set of communication links in S :

L = {(i, j ) | i, j ∈ N all , i ̸= j, Cij = 1}.

(72)

For each link (i, j ) ∈ L, let Bij denote the available bandwidth, Pijtx denote the number of transmitted packets, Pijrx denote the number of successfully received packets, and Pijloss denote the number of lost packets during an observation window ∆t = [t0 , t1 ]. 25

Table 3: Acquisition requirements for network-level metrics. Metric Network Latency Jitter Bandwidth Utilization Packet Loss Rate Packet Delivery Rate Network Throughput Goodput Network Response Time Service Time Queueing Delay Network Congestion Level Network Availability Network Reliability Handover Delay Comm. Energy Consumpt. Comm. Energy Efficiency Connection Density Path Stretch Network Cost Network Service Quality

Scope Multi-Node Single-Node Single-Node Multi-Node Multi-Node Single-Node Single-Node Single-Node Single-Node Single-Node Single-Node Single-Node Single-Node Single-Node* Single-Node Single-Node Full System Full System Single-Node Full System

Phase Operational Operational Operational Operational Operational Operational Operational Operational Operational Operational Operational Operational Operational Operational Operational Experimental Operational Operational Experimental Experimental

Method Standard Telemetry Standard Telemetry Standard Telemetry Standard Telemetry Standard Telemetry Standard Telemetry Custom Instrumentation Standard Telemetry Standard Telemetry Standard Telemetry Standard Telemetry Standard Telemetry Standard Telemetry Standard Telemetry Experimental Instrumentation Experimental Instrumentation Standard Telemetry Standard Telemetry Experimental Instrumentation Experimental Instrumentation

5.1 Network Latency Network latency measures the time required for data to travel from a source node to a destination node [74]. In DCCS, latency is critical because sensor, IoT, edge, and mobile applications often require timely data delivery. For a packet transmitted from node i to node j , one-way latency can be expressed as tx Lij = trx j − ti ,

(73)

rx where ttx i is the transmission time at source node i and tj is the reception time at destination node j . The round-trip time (RTT)[75] between nodes i and j is defined as

RT Tij = treply − trequest , i i

(74)

where trequest is the time when node i sends a request and treply is the time when i i node i receives the corresponding reply. The average network latency over all active communication links is

LS =

1 X Lij . |L| (i,j)∈L

26

(75)

For a multi-hop communication path Psd from source s to destination d, the endto-end latency is

Le2e sd =

X

Lprop + Ltrans + Lqueue + Lproc , ij ij ij ij

(76)

(i,j)∈Psd

is queueing is propagation delay, Ltrans is transmission delay, Lqueue where Lprop ij ij ij proc delay, and Lij is processing delay at intermediate nodes. The transmission delay for a packet of size dp over link (i, j ) is

Ltrans = ij

dp . Bij

(77)

As summarized in Table 3, the minimal acquisition scope is Multi-Node because latency is inherently defined between a source and a destination. Although RTT can be measured from a single endpoint, it still requires participation from the remote node, while one-way latency additionally requires synchronized timestamps at both ends. The acquisition occurs during the Operational phase to detect communication delays during system execution. The acquisition method is Standard Telemetry because latency is provided by standard networking and observability mechanisms.

5.2 Jitter Jitter measures the variation in packet delay over time or the variation in packet delay between consecutive packets. It is especially important for real-time DCCS applications such as autonomous vehicles, remote monitoring, industrial control, augmented reality, and video analytics. If Lpij and Lp−1 are the latencies of two consecutive packets ij transmitted over link (i, j ), packet delay variation can be expressed as p Jij = |Lpij − Lp−1 ij |.

(78)

The average jitter over P received packets is P 1 X p J ij = |L − Lp−1 ij |. P − 1 p=2 ij

(79)

For the complete DCCS, average jitter can be computed as

JS =

1 X J ij . |L|

(80)

(i,j)∈L

A lower jitter value indicates more stable communication. This metric is commonly used in IP performance measurement, especially for delay-sensitive networked systems [76]. The minimal acquisition scope is Single-Node because packet delay variation can be computed locally from consecutive delay measurements collected by a single 27

endpoint. The acquisition occurs during the Operational phase in order to detect communication instability during system execution. The acquisition method is Standard Telemetry because packet delay variation is routinely exposed by standard networking measurement and monitoring tools.

5.3 Bandwidth Utilization Bandwidth utilization measures the fraction of available link capacity that is actually used for data transmission [77]. For a link (i, j ), bandwidth utilization is defined as bw Uij =

Rij , Bij

(81)

where Rij is the actual data transmission rate and Bij is the maximum available bandwidth of link (i, j ). The average bandwidth utilization of the DCCS is

USbw =

1 X bw Uij . |L|

(82)

(i,j)∈L

as

For heterogeneous links, a capacity-weighted bandwidth utilization can be defined P (i,j)∈L Rij bw W US = P . (83) (i,j)∈L Bij

bw A very low value of Uij may indicate underutilized communication resources, while a value close to 1 may indicate congestion risk. The minimal acquisition scope is Single-Node because the transmitted traffic and link capacity can be measured locally at a network interface. The acquisition occurs during the Operational phase in order to detect network resource saturation during system execution. The acquisition method is Standard Telemetry because bandwidth utilization is usually exposed by the OS.

5.4 Packet Loss Rate Packet loss rate measures the fraction of transmitted packets that fail to reach the destination [78]. It is an important metric for evaluating communication reliability in DCCS, especially when data are transmitted from low-power sensor and IoT devices over unreliable wireless links. For a link (i, j ), packet loss rate is defined as

P LRij =

Pijloss , Pijtx

(84)

where Pijloss is the number of lost packets and Pijtx is the number of transmitted packets. Since Pijloss = Pijtx − Pijrx , (85) 28

packet loss rate can also be written as

P LRij =

Pijtx − Pijrx . Pijtx

(86)

The system-level packet loss rate is

P P LRS =

(i,j)∈L

Pijtx − Pijrx

tx (i,j)∈L Pij

P

.

(87)

A high packet loss rate may increase retransmissions, energy consumption, latency, and task failure probability. The minimal acquisition scope is Multi-Node because packet loss is determined by comparing the number of transmitted packets at the sender with the number of received packets at the destination. The acquisition occurs during the Operational phase in order to detect communication reliability degradation during system execution. The acquisition method is Standard Telemetry because transmitted and received packet counters are routinely exposed by network interfaces and monitoring frameworks.

5.5 Packet Delivery Rate Packet delivery rate/ratio is complementary to Packet Loss Rate (P DR = 1 −P LR) and therefore shares the same acquisition scope, phase, and method. It measures the fraction of transmitted packets that are successfully received at the destination. For a link (i, j ), it is defined as Pijrx P DRij = tx . (88) Pij Since packet delivery and packet loss are complementary, the relationship between packet delivery rate and packet loss rate is

P DRij = 1 − P LRij .

(89)

The system-level packet delivery rate is rx (i,j)∈L Pij tx . (i,j)∈L Pij

P

P DRS = P

(90)

For multi-hop communication, if packets travel through path Psd , the end-to-end packet delivery rate can be approximated as e2e P DRsd =

Y (i,j)∈Psd

29

P DRij .

(91)

5.6 Network Throughput Network throughput measures the amount of useful data successfully delivered per unit time. Unlike bandwidth, which represents the theoretical or provisioned capacity, throughput represents the actual achieved data transmission rate [79, 80]. For a link (i, j ), throughput is defined as rx Dij net T Hij = , (92) ∆t rx where Dij is the amount of successfully received data over link (i, j ) during ∆t. The total network throughput of the DCCS is rx (i,j)∈L Dij

P T HSnet =

∆t

.

(93)

Layer-wise network throughput can be defined as

P T HXnet =

i∈X

rx j∈N all Dij

P

∆t

,

(94)

where X ∈ {Ψ, Γ, M, E, F, C}. This metric helps identify which layer generates or carries the highest amount of traffic. The minimal acquisition scope is Single-Node because the amount of successfully received data can be measured locally at the receiving endpoint. The acquisition occurs during the Operational phase in order to detect communication performance during system execution. The acquisition method is Standard Telemetry because received byte counters and data rates are routinely exposed by network interfaces and OS.

5.7 Goodput Goodput measures the amount of useful application-level data delivered per unit time [81, 82]. Unlike throughput, goodput excludes retransmissions, duplicate packets, protocol headers, and control messages. For link (i, j ), goodput can be defined as

GPij =

usef ul Dij , ∆t

(95)

usef ul where Dij is the successfully delivered useful application data. The system-level goodput is usef ul (i,j)∈L Dij

P GPS =

∆t

.

(96)

Goodput efficiency can be defined as

GP ES =

30

GPS . T HSnet

(97)

A higher value of GP ES indicates that most transmitted data are useful application-level data. The minimal acquisition scope is Single-Node because useful application data can be measured locally at the receiving endpoint. The acquisition occurs during the Operational phase in order to evaluate effective communication performance during system execution. The acquisition method is Custom Instrumentation because the application must define which transmitted data are considered useful, requiring application-level instrumentation.

5.8 Response Time Network response time measures the time between sending a request and receiving the corresponding response. It is useful for client-server, cloud, edge, and service-oriented DCCS applications. For a request generated by node i and served by node j , response time can be expressed as

RTijnet = tresponse − trequest . i i

(98)

res RTijnet = Lreq ij + STj + Lji ,

(99)

It can be decomposed as

res where Lreq ij is request transmission latency, STj is service time at node j , and Lji is response transmission latency. The average network response time is net

RT S

=

1 X RTrnet , |R|

(100)

r∈R

where R is the set of completed network requests. The minimal acquisition scope is Single-Node because the elapsed time between sending a request and receiving the corresponding response can be measured locally by the client. The acquisition occurs during the Operational phase in order to detect communication delays during system execution. The acquisition method is Standard Telemetry because request and response timings are routinely exposed by standard networking and distributed tracing instrumentation.

5.9 Service Time Service time measures the time spent by a network or computing node to process a request after receiving it. In DCCS, service time may include protocol handling, packet inspection, routing decision, data aggregation, task offloading decision, and local computation. For a request r served by node j , service time is

− tarrival , STjr = tcomplete j,r j,r 31

(101)

is the time where tarrival is the time when request r arrives at node j , and tcomplete j,r j,r when node j completes the service. The average service time of node j is

ST j =

1 X STjr , |Rj |

(102)

r∈Rj

where Rj is the set of requests served by node j . The system-level average service time is

ST S =

1 X ST j . ζ

(103)

j∈N

The minimal acquisition scope is Single-Node because the arrival and completion times of a request are both measured locally at the serving node. The acquisition occurs during the Operational phase in order to detect processing delays during system execution. The acquisition method is Standard Telemetry because request processing durations are routinely exposed by standard tracing and monitoring instrumentation.

5.10 Queueing Delay Queueing delay measures the time a packet or request spends waiting in a buffer before transmission or processing. It is an important metric because congestion in edge, fog, or gateway nodes may increase the total response time. For packet p waiting at node j , queueing delay is

QDjp = tservice − tarrival , j,p j,p

(104)

where tarrival is the packet arrival time and tservice is the time when service begins. j,p j,p The average queueing delay at node j is Pj

QDj =

1 X QDjp , Pj p=1

(105)

where Pj is the number of packets arriving at node j . The minimal acquisition scope is Single-Node because packet arrival and service start times are both measured locally at the queue. The acquisition occurs during the Operational phase in order to detect congestion during system execution. The acquisition method is Standard Telemetry because queue occupancy and waiting times are routinely exposed by OS, network devices, and tracing instrumentation.

5.11 Network Congestion Level Network congestion occurs when the traffic demand exceeds the available transmission or processing capacity. A simple congestion level for link (i, j ) can be defined using 32

bandwidth utilization and queue occupancy: bw CGij = aUij + (1 − a)Ujbuf ,

(106)

bw where Uij is bandwidth utilization, Ujbuf is buffer utilization at node j , and 0 ≤ a ≤ 1. The system-level congestion level is

CGS =

1 X CGij . |L|

(107)

(i,j)∈L

A congestion-aware packet drop probability can also be defined as

Pjdrop =

Pjdrop , Pjarr

(108)

where Pjdrop is the number of packets dropped at node j and Pjarr is the number of packets arriving at node j . The minimal acquisition scope is Single-Node because it is computed from bandwidth utilization and buffer occupancy, both of which can be measured locally, as previously mentioned. The acquisition occurs during the Operational phase in order to detect congestion during system execution. The acquisition method is Standard Telemetry because bandwidth, queue occupancy, and packet drop counters are routinely exposed by network devices and OS.

5.12 Network Availability Network availability measures the probability that a communication link, path, or network service is operational. For a communication link (i, j ), availability can be expressed as M T T Fij Anet , (109) ij = M T T Fij + M T T Rij where M T T Fij is the mean time to failure and M T T Rij is the mean time to repair of link (i, j ). The average network availability of the DCCS is

Anet S =

1 X Anet ij . |L|

(110)

(i,j)∈L

For a multi-hop path Psd , path availability can be computed as

Apath = sd

Y (i,j)∈Psd

33

Anet ij .

(111)

If multiple redundant paths Psd are available between source s and destination d, the redundant path availability is

Y

Ared sd = 1 −



 1 − Apath . sd

(112)

Psd ∈Psd

The minimal acquisition scope is Single-Node because link or service availability can be monitored locally using heartbeat or connectivity checks through pings. The acquisition occurs during the Operational phase in order to detect communication outages during system execution. The acquisition method is Standard Telemetry because availability is routinely monitored through standard heartbeat, keep-alive, and network monitoring mechanisms.

5.13 Network Reliability Network reliability measures the probability that a communication link or path successfully operates without failure for a given time duration. If λij is the failure rate of link (i, j ), link reliability over time t can be expressed as net Rij (t) = e−λij t .

(113)

The reliability of a communication path Psd is path Rsd (t) =

Y

net Rij (t).

(114)

(i,j)∈Psd

For redundant communication paths, reliability can be improved as red Rsd (t) = 1 −

Y



 path 1 − Rsd (t) .

(115)

Psd ∈Psd

The minimal acquisition scope is Single-Node because link failures can be monitored locally to estimate the failure rate and reliability. The acquisition occurs during the Operational phase in order to detect communication failures during system execution. The acquisition method is Standard Telemetry because failure events and uptime are routinely exposed by standard network monitoring mechanisms.

5.14 Handover Delay Handover delay is important in DCCS when mobile devices M move between different access points, edge nodes, or fog nodes [83, 84]. It measures the interruption time during mobility-driven service migration or network reconnection. For mobile node Mi , handover delay can be defined as old HDMi = tnew connect − tdisconnect ,

34

(116)

new where told disconnect is the time when Mi disconnects from the previous node, and tconnect is the time when it connects to the new node. The average handover delay for all mobile devices is

HDM =

1 X HDMi . m

(117)

Mi ∈M

A handover failure rate can be defined as

HF R =

H f ail , H total

(118)

where H f ail is the number of failed handovers and H total is the total number of handover attempts. The minimal acquisition scope is Single-Node * because the disconnection and reconnection times can be measured locally by the mobile device. Without instrumentation on the mobile device, telemetry from multiple nodes would be required. The acquisition occurs during the Operational phase in order to detect mobility-related communication interruptions during system execution. The acquisition method is Standard Telemetry because handover events are routinely exposed by the OS through network interface state changes and connectivity events.

5.15 Communication Energy Consumption Energy consumption during communications is a metric that measures the energy spent for transmitting, receiving, and listening to network traffic [85, 86]. This metric is essential for battery-powered sensor, IoT, edge, and mobile devices, and continuously exchange control signals and messages among devices over the network. For node i, communication energy consumption can be expressed as

Eicomm = Eitx + Eirx + Eiidle ,

(119)

where Eitx is transmission energy, Eirx is reception energy, and Eiidle is idle listening energy. For data transmission from node i to node j , transmission energy can be approximated as tx Eij = Pitx × Tijtx , (120) where Pitx is the transmission power of node i and Tijtx is the transmission duration. If dij amount of data is transmitted over bandwidth Bij , then

Tijtx =

dij . Bij

(121)

The total communication energy consumption of the DCCS is

EScomm =

X i∈N all

35

Eicomm .

(122)

The minimal acquisition scope is Single-Node because communication energy can be measured or estimated independently for each node. The acquisition occurs during the Operational phase in order to monitor the communication energy consumption of battery-powered devices during system execution. The acquisition method is Experimental Instrumentation because communication energy is not directly exposed by standard telemetry and typically requires hardware power measurements or energy estimation models. Communication energy efficiency measures the amount of successfully delivered data per unit communication energy. It can be defined as rx (i,j)∈L Dij . EScomm

P CEES =

(123)

For useful application-level data, goodput-based communication energy efficiency is

usef ul (i,j)∈L Dij . EScomm

P GCEES =

(124)

A higher value indicates that the network delivers more useful data with less energy consumption. The minimal acquisition scope is Single-Node because both the delivered data and communication energy can be measured or estimated independently for each node. The acquisition occurs during the Experimental phase in order to evaluate the energy efficiency of communication mechanisms and network configurations. The acquisition method is Experimental Instrumentation because it depends on communication energy measurements, which typically require hardware power measurements or energy estimation models.

5.16 Connection Density Connection density measures measures the proportion of direct communication links among the nodes of the system. It is useful for understanding the connectivity structure of the system. The maximum possible number of directed links among n devices is n(n − 1). Therefore, directed connection density can be defined as

Pn

i=1

CDS =

Pn

j=1 Cij j̸=i

n(n − 1)

.

(125)

For undirected communication links, the connection density is

CDS =

2|L| . n(n − 1)

(126)

A very low value may indicate poor connectivity, while a very high value may increase maintenance complexity and network management overhead. The minimal acquisition scope is Full System because the complete network topology is required to determine the total number of nodes and communication links. The acquisition occurs 36

during the Operational phase in order to monitor changes in the communication topology during system execution. The acquisition method is Standard Telemetry because network topology is routinely exposed through kernel networking interfaces (e.g., Netlink) and topology discovery protocols.

5.17 Path Stretch Path stretch measures how much longer the selected communication path is compared with the shortest possible path. For a source-destination pair (s, d), it is defined as

P Ssd =

selected Cost(Psd ) , shortest ) Cost(Psd

(127)

where Cost(P ) may represent hop count, latency, energy, or routing cost. If latency is used as the cost, then lat P Ssd =

selected L(Psd ) . shortest L(Psd )

(128)

A value close to 1 indicates efficient routing, while a larger value indicates suboptimal path selection. The minimal acquisition scope is Full System because evaluating the selected path against the shortest possible path for a source-destination pair requires knowledge of the complete communication graph. The acquisition occurs during the Operational phase in order to evaluate routing efficiency during system execution. The acquisition method is Standard Telemetry because the communication graph can be obtained from kernel networking information (e.g., Netlink) or reconstructed from distributed traces.

5.18 Network Cost Network cost measures the operational or monetary cost of communication. This can include data transfer cost, network usage cost, energy cost, and service provider cost. For a link (i, j ), communication cost can be represented as tx Costnet ij = κij Dij ,

(129)

tx where κij is the cost per unit data transmitted over link (i, j ) and Dij is the transmitted data volume. The total network cost of DCCS is X Costnet Costnet (130) ij . S = (i,j)∈L

Cost per successfully delivered data unit can be defined as

Costnet S rx . (i,j)∈L Dij

CP D = P

37

(131)

Table 4: Acquisition requirements for application or user-level metrics. Metric Task Success Ratio Application Cost Time & Space Complexity Accuracy Availability SLO and SLA Compliance Error Rate Efficiency Metrics User Satisfaction Metrics Learnability Metrics Flexibility Application Portability Application Robustness

Scope Full App Full App Full App Single-Node Full App Full App Full App Full App Single-Node Single-Node Full System Full System Full App

Phase Operational Experimental* Experimental Experimental Operational Operational Operational Operational Experimental Experimental Operational Experimental Experimental

Method Custom Instrumentation Experimental Instrumentation Standard Telemetry Experimental Instrumentation Standard Telemetry Experimental Instrumentation Standard Telemetry* Custom Instrumentation Experimental Instrumentation Custom Instrumentation Custom Instrumentation Custom Instrumentation Custom Instrumentation*

The minimal acquisition scope is Single-Node because transmitted data can be measured independently for each node. The acquisition occurs during the Experimental phase in order to evaluate communication strategies and deployment configurations. Although it can also be used by cost-aware orchestration systems at runtime, this remains application-dependent. The acquisition method is Experimental Instrumentation because communication cost depends on external pricing or energy models rather than standard telemetry, and there is no universally accepted method to derive them.

6 Application or User-level Performance Measurement Application or user-level performance measurement evaluates how well a DCCS satisfies application requirements and user expectations. While computing-level metrics focus on resource execution and network-level metrics focus on communication performance, application-level metrics measure the quality perceived by applications, users, and service providers. These metrics include task success, cost, time and space complexity, accuracy, availability, error rate, flexibility, user satisfaction, service-level objective compliance, and learnability. Further, table 4 summarizes the acquisition requirements associated with each application-level metric. Let A = {A1 , A2 , . . . , Aa } denote the set of applications deployed over S . Each application Al ∈ A consists of a set of tasks TAl = {T1 , T2 , . . . , Tq }. A task Ti (similar to Eq. (2)) is represented as

Ti = ⟨ωi , di , τi , δi , γi ⟩,

(132)

where ωi is the computational workload, di is the input data size, τi is the task arrival time, δi is the deadline, and γi is the expected application-level quality requirement. 38

Let TAcl denote the set of completed tasks, TAfl denote the set of failed tasks, and TAsl denote the set of successfully completed tasks for application Al .

6.1 Task Success Metrics Task success measures whether an application task is completed correctly and within the required constraints. In DCCS, a task may be considered successful only if it satisfies functional correctness, deadline, quality, and resource constraints. The task success ratio of application Al is defined as

T SRAl =

|TAsl | . |TAl |

(133)

For deadline-constrained applications, deadline-aware task success ratio is defined as

|TAs,δ | l DT SRAl = , |TAl |

(134)

where TAs,δ is the set of tasks that are successfully completed before their deadlines. l If a task must satisfy both correctness and deadline constraints, then

( Tis =

1, if Correct(Ti ) = 1 and RTi ≤ δi , 0, otherwise.

(135)

The application-level task success ratio can then be written as

T SRAl =

X 1 Tis . |TAl |

(136)

Ti ∈TAl

For DCCS applications where output quality is important, a quality-aware task success ratio can be defined as

QT SRAl =

X 1 |TAl |

1(RTi ≤ δi ∧ Qi ≥ γi ),

(137)

Ti ∈TAl

where Qi is the achieved output quality, γi is the minimum required quality, and 1(·) is an indicator function. The minimal acquisition scope is Full App because T SRAl is defined over all tasks belonging to an application, which may execute on multiple nodes. However, it can be collected from a single node when the application is entirely executed there. The acquisition occurs during the Operational phase in order to monitor task execution during system operation. The acquisition method is Custom Instrumentation because the application must define what constitutes a successfully completed task, such as satisfying correctness, deadline, or quality constraints. 39

6.2 Cost Application-level cost measures the monetary or operational cost required to execute an application over the DCCS [87, 88]. The total cost of application Al can include computing cost, communication cost, storage cost, energy cost, and migration cost: eng mig CostAl = Costcomp + Costcomm + Coststo Al Al + CostAl + CostAl . Al

(138)

The computing cost can be expressed as

Costcomp = Al

X X

xij κcomp ETij , j

(139)

Ti ∈TAl j∈N

where xij indicates whether task Ti is assigned to computing node j , κcomp is the j computing cost per unit time of node j , and ETij is the execution time of task Ti on node j . The communication cost is X tx Costcomm = κcomm Dij , (140) Al ij (i,j)∈LAl tx where κcomm is the communication cost per unit data over link (i, j ), and Dij is the ij transmitted data volume. The cost per successful task is defined as

CostAl . |TAsl |

(141)

|TAsl | . CostAl

(142)

CP STAl = The cost efficiency of application Al is

CEAl =

For quality-aware applications, the cost-quality efficiency can be expressed as P Ti ∈TAs Qi l CQEAl = . (143) CostAl The minimal acquisition scope is Full App because the metric aggregates the execution cost of all resources involved in the application, which may span multiple nodes. The acquisition occurs during the Experimental * phase because application cost is primarily used to evaluate deployment strategies and resource allocation. Although it can also be used by cost-aware orchestration systems at runtime, this remains application-dependent. The acquisition method is Experimental Instrumentation because it depends on external pricing or energy models rather than standard telemetry, and there is no universally accepted method to derive it. 40

6.3 Time and Space Complexity Time and space complexity describe the growth of application execution time and memory requirements with respect to input size. This traditional metrics not only applicable user level but also influence the systems level. Let ni denote the input size of task Ti . The theoretical time complexity of the algorithm used by application Al can be represented as T CAl (ni ) = O(g (ni )), (144) where g (ni ) represents the growth function of execution time. The observed execution time of application Al over DCCS is

OETAl =

X X

xij ETij .

(145)

Ti ∈TAl j∈N

In DCCS, the practical application completion time also includes communication and coordination overhead:

ACTAl =

X

(ETi + CTi + QTi + SYi + M Gi ) ,

(146)

Ti ∈TAl

where ETi is execution time, CTi is communication time, QTi is queueing time, SYi is synchronization time, and M Gi is migration time. The space complexity of application Al is represented as

SCAl (ni ) = O(h(ni )),

(147)

where h(ni ) represents the growth function of memory consumption. The observed memory usage of application Al is

OM UAl =

X

used , Mj,A l

(148)

j∈N used denotes the memory consumed by application Al on node j . where Mj,A l A continuum overhead ratio can be defined as

CORAl =

ACTAl − OETAl . ACTAl

(149)

A lower value of CORAl indicates that less time is spent on communication, synchronization, queueing, and migration overhead. The minimal acquisition scope is Full App because the observed execution time, memory usage, and continuum overhead are aggregated across all tasks and nodes belonging to the application. The acquisition occurs during the Experimental phase because these metrics are primarily used to evaluate scalability and identify the most efficient algorithms, deployments, or execution configurations by comparing different executions. The acquisition 41

method is Standard Telemetry because execution times, memory usage, communication delays, synchronization events, and migration events are routinely exposed by OS, orchestrators, and distributed tracing frameworks.

6.4 Accuracy Accuracy measures the correctness of application outputs. In DCCS, accuracy is important for applications such as classification, prediction, object detection, anomaly detection, decision support, and control. For classification-based applications, accuracy is defined as TP + TN Acc = , (150) TP + TN + FP + FN where T P , T N , F P , and F N denote true positives, true negatives, false positives, and false negatives, respectively. Precision is defined as TP , (151) P recision = TP + FP and recall is defined as TP Recall = . (152) TP + FN The F1-score is the harmonic mean of precision and recall:

F1 = 2 ×

P recision × Recall . P recision + Recall

(153)

For regression or prediction-based applications, mean absolute error can be used: N

M AE =

1 X |yi − ŷi |, N i=1

(154)

where yi is the actual value and ŷi is the predicted value. Mean squared error is defined as N

1 X (yi − ŷi )2 . M SE = N i=1

(155)

Root mean squared error is

v u N u1 X RM SE = t (yi − ŷi )2 . N i=1

(156)

For DCCS, accuracy can also be measured under resource constraints. Therefore, resource-aware accuracy can be defined as

RAccAl =

AccAl , w1 RTAl + w2 EAl + w3 CostAl 42

(157)

where RTAl is response time, EAl is energy consumption, CostAl is application cost, and w1 , w2 , and w3 are weighting factors. The minimal acquisition scope is SingleNode because this metric is evaluated on the prediction or inference nodes, and all the required information can be obtained from a single node when the inference is performed locally. Applications requiring distributed inference would instead require telemetry from multiple nodes. The acquisition occurs during the Experimental phase because evaluating accuracy requires comparing predictions against reference outputs, making it primarily suitable for validation, benchmarking, and model selection rather than continuous runtime monitoring. The acquisition method is Experimental Instrumentation because it requires external ground truth or an oracle to determine whether the produced outputs are correct.

6.5 Availability Application-level availability measures the probability that an application is accessible and operational when requested by users. It can be defined using uptime and downtime:

AAl =

TAupl TAupl + TAdown l

,

(158)

is the total downtime. where TAupl is the total application uptime and TAdown l Using mean time to failure and mean time to repair, availability can also be expressed as M T T FAl AAl = . (159) M T T FAl + M T T RAl For an application deployed across multiple continuum layers, application availability depends on the availability of required computing nodes, communication links, and software services. If application Al requires a set of nodes NAl and links LAl , then a simple serial dependency availability model can be expressed as = Aserial Al

Y

Y

Aj

j∈NAl

Anet ij .

(160)

(i,j)∈LAl

If the application can use redundant nodes or alternative paths, availability can be improved as Y (1 − Ar ), (161) Ared Al = 1 − r∈RAl

where RAl represents redundant application instances, alternative execution paths, or service replicas. The minimal acquisition scope is Full App because, although an application may be accessible through a single entry point, the metric evaluates whether the entire application remains operational. This generally requires considering the availability of all nodes involved in the application, or at least those required to execute the requested functionality. The acquisition occurs during the Operational phase in order to detect service interruptions and ensure that the application remains 43

accessible during system execution. The acquisition method is Standard Telemetry because application availability is routinely monitored through health checks, heartbeat mechanisms, service status monitoring, and uptime records.

6.6 SLO and SLA Compliance Service-level objectives (SLOs) and service-level agreements (SLAs) define expected service quality from the application or user perspective [89]. Let OAl = {O1 , O2 , . . . , Oo } denote the set of SLOs for application Al . Each SLO Or can be represented as Or = ⟨mr , θr , ⋄r ⟩, (162) where mr is the measured metric, θr is the target threshold, and ⋄r ∈ {≤, ≥} is the satisfaction condition. The SLO satisfaction indicator is ( 1, if mr ⋄r θr , (163) Sat(Or ) = 0, otherwise. The SLO compliance ratio of application Al is

SLOCRAl =

1 |OAl |

X

Sat(Or ).

(164)

Or ∈OAl

For task-level SLOs, the compliance ratio can be defined as

T SLOCRAl =

X 1 |TAl |

). 1 (RTi ≤ δi ∧ Qi ≥ γi ∧ Costi ≤ Costmax i

(165)

Ti ∈TAl

An SLA violation rate can be defined as

SLAV RAl = 1 − SLOCRAl .

(166)

The minimal acquisition scope is Full App because, although SLO and SLA compliance can be evaluated by a single monitoring component, that component requires telemetry from all application components involved in delivering the requested service. Therefore, the acquisition scope is transitively the application. The acquisition occurs during the Operational phase in order to continuously verify that the application satisfies its service-level objectives during execution. It can also support SLO-aware applications that dynamically adapt their configuration or resource allocation at runtime to maintain compliance. The acquisition method is Experimental Instrumentation because SLO and SLA compliance require an external governance component that defines the objectives, collects telemetry from the monitored system, and evaluates whether the agreements are satisfied, as performed by frameworks such as Governify [90]. 44

6.7 Error Rate Error rate measures the fraction of application operations, tasks, requests, or user actions that result in incorrect or failed outcomes. The task error rate of application Al is defined as

ERAl =

|TAerr | l , |TAl |

(167)

where TAerr is the set of tasks that produce incorrect outputs or fail due to applicationl level errors. If user actions are considered, user error rate is defined as user Nerr , user Nact

U ER =

(168)

user user where Nerr is the number of incorrect user actions and Nact is the total number of user actions. For request-based applications, request error rate can be expressed as f ailed Nreq . total Nreq

(169)

recovered Nerr , total Nerr

(170)

RERAl = The recoverable error ratio is rec = RERA l

recovered where Nerr is the number of errors successfully recovered by the system. The minimal acquisition scope is Full App because the metric is defined over all tasks or requests belonging to the application, requiring the aggregation of errors across the application’s execution. The acquisition occurs during the Operational phase in order to detect failures and monitor the application’s health during execution. The acquisition method is Standard Telemetry * because failed requests and unsuccessful task executions are routinely exposed by logs and distributed tracing frameworks. However, application-specific definitions of incorrect outcomes may require Custom Instrumentation .

6.8 Efficiency Metrics Application efficiency measures how much useful output is produced relative to time, cost, energy, or resources. The time efficiency of application Al is

T EAl =

|TAsl | . ACTAl

45

(171)

Energy efficiency is defined as

EEAl =

|TAsl | , EAl

(172)

where EAl is the total energy consumed by application Al . Resource efficiency can be expressed as

|TAsl | res , j∈N Uj,Al

REAl = P

(173)

res where Uj,A denotes the amount of resources consumed by application Al on node j . l A combined application efficiency score can be defined as

d d A + yb3 EE d A + yb4 RE dA , AEAl = yb1 T E Al + yb2 CE l l l

(174)

d d A , EE d A , and RE d A are normalized time, cost, energy, and resource where T E Al , CE l l l efficiency values, respectively, and yb1 + yb2 + yb3 + yb4 = 1. The minimal acquisition scope is Full App because the metrics are computed from the successful tasks and resource consumption of the application as a whole. The acquisition occurs during the Operational phase in order to monitor the application’s efficiency and detect performance degradation during execution. The acquisition method is Custom Instrumentation because the metrics depend on the application-specific definition of successful task completion, while the remaining quantities, such as execution time, energy, cost, and resource usage, can be obtained through standard telemetry.

6.9 User Satisfaction Metrics User satisfaction measures the perceived quality of the application by end users. It can be collected through feedback scores, ratings, surveys, or interaction logs. Let su denote the satisfaction score given by user u, where su ∈ [1, 5] or su ∈ [1, 10]. The average user satisfaction score is

U SS =

1 X su , |U|

(175)

u∈U

where U is the set of users. A normalized user satisfaction score can be expressed as

N U SS =

U SS − smin , smax − smin

(176)

where smin and smax are the minimum and maximum possible satisfaction scores. 46

For interactive DCCS applications, satisfaction may depend on latency, availability, accuracy, and error rate. Therefore, a quality-of-experience score can be defined as

d A + η2 A bA + η3 T[ dA − η5 ER dA , QoEAl = η1 Acc SRAl − η4 RT l l l l

(177)

dA , A bA , and T[ dA and where Acc SRAl are normalized positive indicators, while RT l l l d ERAl are normalized negative indicators. The minimal acquisition scope is SingleNode because user satisfaction is typically collected and stored by a single feedback or analytics component that acts as the source of truth. Therefore, instrumenting the application nodes themselves is not required to obtain the metric. The acquisition occurs during the Experimental phase because user satisfaction is primarily used to evaluate and compare application designs, configurations, or deployments from the users’ perspective. The acquisition method is Experimental Instrumentation because user satisfaction requires an external feedback collection mechanism, such as surveys, ratings, questionnaires, or interaction analysis, which must be specifically instrumented to expose these data.

6.10 Learnability Metrics Learnability measures how easily users learn to use an application. It is particularly relevant for human-facing DCCS applications, dashboards, mobile interfaces, digital twins, and control systems. Let T T Fu denote the time taken by user u to complete a task correctly for the first time. The average time-to-first-success is

AT F S =

1 X T T Fu . |U|

(178)

u∈U

The first-attempt success ratio is

F ASR =

f irst Nsuccess f irst Nattempt

,

(179)

f irst where Nsuccess is the number of users who successfully complete the task on the first f irst attempt, and Nattempt is the total number of first attempts. Learning improvement between two sessions can be defined as

LI =

session1 session2 Tavg − Tavg , session1 Tavg

(180)

session1 session2 where Tavg and Tavg are average task completion times in the first and second sessions, respectively. Error reduction due to learning can be expressed as

ERL =

ERsession1 − ERsession2 . ERsession1 47

(181)

The minimal acquisition scope is Single-Node because user interaction events can typically be collected by a single frontend or analytics component without requiring instrumentation of the entire application. The acquisition occurs during the Experimental phase because learnability is primarily evaluated during usability studies or controlled deployments to assess and compare interface designs and user experience. The acquisition method is Custom Instrumentation because the application must record user-specific events such as first attempts, successful task completions, and session progression, which are not provided by standard telemetry frameworks.

6.11 Flexibility Flexibility measures the ability of an application to adapt to changing users, workloads, deployment environments, devices, and quality requirements. In DCCS, flexibility is important because applications may need to move across cloud, fog, edge, mobile, and IoT layers. The deployment flexibility of application Al can be defined as

DFAl =

|NAeligible | l , |N |

(182)

where NAeligible is the set of computing nodes capable of executing application Al . l The migration flexibility can be defined as

M FAl =

mig | |PA l all | |PA l

,

(183)

mig all is the set of feasible migration paths and PA is the set of all possible where PA l l migration paths. The configuration flexibility can be defined as

CFAl =

valid Nconf ig total Nconf ig

,

(184)

valid where Nconf ig is the number of valid application configurations that satisfy minimum total requirements, and Nconf ig is the total number of possible configurations. An application flexibility score can be computed as

F SAl = wi1 DFAl + w2 M FAl + w3 CFAl + w4 AFAl ,

(185)

where AFAl denotes adaptation flexibility, and w1 + w2 + w3 + w4 = 1. The minimal acquisition scope is Full System because evaluating deployment, migration, and configuration flexibility requires knowledge of all available computing nodes and resources in the DCCS to determine which are eligible for the application. The acquisition occurs during the Operational phase in order to support adaptation decisions as the set of available resources and deployment opportunities changes during system execution. 48

The acquisition method is Custom Instrumentation because the application must define eligibility rules, valid configurations, and feasible migration paths, which are application-specific and cannot be inferred from standard telemetry alone.

6.12 Application Portability Application portability measures the ability of an application to be deployed or migrated across heterogeneous continuum nodes without major modification. Let PAl denote the set of platforms that support application Al , and P all denote the set of all available platforms in S . Portability can be defined as

|PAl | . |P all |

P RTAl =

(186)

A dependency-aware portability metric can be defined as

DP RTAl = 1 −

unsatisf ied Ndep total Ndep

,

(187)

unsatisf ied where Ndep is the number of unsatisfied software, hardware, or network depentotal dencies, and Ndep is the total number of dependencies. The minimal acquisition scope is Full System because portability must be evaluated against all available platforms and resources in the DCCS to determine where the application can be successfully deployed. The acquisition occurs during the Experimental phase because portability is primarily assessed when evaluating deployment strategies, target infrastructures, or application designs before deployment. The acquisition method is Custom Instrumentation because the application must define its platform compatibility and software, hardware, and network dependencies, which cannot be inferred from standard telemetry alone.

6.13 Application Robustness Application robustness measures the ability of an application to continue producing acceptable outputs under failures, uncertainty, workload changes, and resource variations. Let Qnormal be the output quality of task Ti under normal conditions and i Qstress be the output quality under stressed conditions. Robustness can be defined as i

ROBAl =

X Qstress 1 i . normal |TAl | Q i T ∈T i

(188)

Al

For deadline-sensitive applications, robustness can also be measured using the degradation in deadline-aware task success: normal stress DROBAl = 1 − DT SRA − DT SRA . l l

49

(189)

A value close to 1 indicates that the application maintains similar performance under normal and stressed conditions. The minimal acquisition scope is Full App because robustness is evaluated over the quality degradation of tasks belonging to the application under stressed conditions. The acquisition occurs during the Experimental phase because robustness evaluation requires controlled experiments that introduce stress conditions and compare application behavior against normal executions to improve the design of more resilient applications. The acquisition method is Custom Instrumentation * because the application must define how task quality and acceptable outputs are measured under stress conditions. In some cases, robustness evaluation may require Experimental Instrumentation when it depends on external data sources, complex models, or previously unavailable measurements.

7 Novel Metric for Changing DCC demands Researchers have proposed a wide range of performance measures for computing systems over the years. Yet as these systems keep growing in scale and complexity, and applications place ever-changing demands on them, many of the established metrics no longer tell the full story. This gap calls for fresh evaluation approaches that can capture what actually matters in today’s distributed environments.

7.1 CO2 emissions GenAI and LLMs are among the most resource-hungry workloads in modern computing, and their environmental footprint reflects that. Training a state-of-the-art model can consume electricity on par with what several hundred homes use over an entire year, generating hundreds of tons of (CO2 ) along the way. Once deployed, these models continue to draw substantial power for everyday inference — often more per query than a standard web search. The data centers hosting them also require considerable water for cooling, which can strain local supplies. At the current pace, data-center carbon emissions could triple by 2030 to roughly 2.5 billion tons a year. Manufacturing the GPUs and accelerators that make all of this possible only adds to the tally. Now consider what happens when GenAI starts running not in a handful of data centers but on millions of IoT and edge devices scattered around the world (e.g., smart home assistants, wearable health monitors, industrial sensors, autonomous vehicles, and everything in between). The energy implications are striking. These devices typically operate where power and cooling are scarce (e.g., on a factory floor, on someone’s wrist, or inside a moving car). Even a lightweight AI model needs meaningful processing power, which translates into faster battery drain, greater hardware wear, and more frequent maintenance. At scale, the combined energy demand of all those devices can strain electricity grids and noticeably increase global CO2 output. Designing new system models for the computing continuum, therefore, demands that carbon-related metrics be built in from the start. One concrete step in this direction comes from Vahdat et al. [91], who proposed a goodput metric that captures carbon dioxide and equivalent emissions alongside traditional performance indicators. Their formulation draws on the Greenhouse Gas 50

Table 5: A summary of Acquisition requirements for novel performance metrics for DCC. Metric CO2 Emissions Heat Dissipation Bottlenecks Measure Observability Adaptivity Quotient Maintain Equilibrium Data Locality Index CC Fragmentation Index Migration Stability Index Adaptation Cost Efficiency SLO Viol. Recovery Time C. Efficiency per Useful Task Water Usage Efficiency Data Freshness Trustworthiness Score

Scope Single-Node Single-Node Full System Full System Full System Full System Multi-Node Full System Full System Multi-Node Full App Full App Full App Multi-Node Single-Node

Phase Operational Operational Operational Experimental Experimental Experimental Operational Operational Operational Experimental Operational Experimental Experimental Operational Operational

Method Experimental Instrumentation Experimental Instrumentation Standard Telemetry Experimental Instrumentation Standard Telemetry* Experimental Instrumentation Standard Telemetry Standard Telemetry Standard Telemetry Experimental Instrumentation Experimental Instrumentation Experimental Instrumentation Experimental Instrumentation Standard Telemetry Experimental Instrumentation

Protocol and ISO standards 14040 and 14044, lending it the rigour needed for consistent, cross-system comparisons. In DCC and IoT environments, where sustainability pressures are growing and device footprints add up quickly, such a metric fills an increasingly important gap. This section introduce various novel performance metrics according to the changes in computational demands due to AI and Table 5 summarizes their acquisition requirements.

7.2 Heat Dissipation Heat dissipation sits alongside CO2 emissions as a key indicator of a system’s environmental footprint. Every active device turns some of its power into waste heat; how efficiently that heat is removed determines cooling costs, hardware reliability, and long-term sustainability. The standard starting point for modelling heat loss is Newton’s law of cooling [92], which ties the cooling rate to the temperature gap between device and

T (t) = Te + T0 − Te e−kt ,

(190)

where T (t) is the device temperature at time t; Te denotes the ambient (environmental) temperature of the location where the device is deployed; T0 represents the initial temperature of the device; k is a positive constant that depends on the properties of the device and the cooling medium (i.e., it determines the rate of heat loss); and e denotes Euler’s number (approximately 2.718), which is the base of the natural logarithm. Simple as it is, this model gives designers a practical tool for predicting temperature evolution and right-sizing cooling strategies across every layer of the continuum (i.e., from warehouse-scale data centers to palm-sized IoT sensors). The minimal acquisition scope is Single-Node because the heat generated by each device can be measured or estimated locally and later aggregated to characterize the 51

thermal footprint of the entire DCCS. The acquisition occurs during the Operational phase in order to monitor the thermal behavior of deployed devices, detect overheating conditions, and evaluate thermal efficiency over time. The acquisition method is Experimental Instrumentation because heat dissipation can be estimated from experimental measurements of the temperature difference between the inside and outside of the enclosure, rather than from standard telemetry.

7.3 Bottlenecks In DCC, resource usage is often uneven. Some devices may be heavily loaded with tasks while others remain underutilized. Similarly, energy consumption can be much higher on certain nodes, and bandwidth availability may fluctuate across different parts of the network. These conditions create potential bottlenecks that are often hidden when relying on average metrics, as such measures tend to smooth out the underlying imbalances. To effectively identify and measure these hidden bottlenecks, the fairness index provides a valuable tool for assessing how evenly resources are distributed across the system. Jain’s fairness index is one of the most popular metric to measure it [93], and shown in Eq. (191).

2 Pn i=1 xi P F (x1 , x2 , . . . , xn ) = n n i=1 x2i

(191)

where xi represents the resource metric for the ith node—such as CPU load, energy consumption, or bandwidth usage—and n is the total number of nodes. The index produces a value between 0 and 1, where 1 indicates perfect no bottlenecks, and values closer to 0 indicate increasing bottlenecks. Several fairness index variants based on Jain’s approach have been proposed; Donta et al. [66] offers an alternate formulation. The minimal acquisition scope is Full System because bottlenecks are identified by comparing the resource utilization of all participating nodes. The acquisition occurs during the Operational phase in order to detect resource imbalances during execution and support load balancing, and resource management decisions. The acquisition method is Standard Telemetry because the required resource metrics, such as CPU utilization, memory usage, bandwidth consumption, and energy consumption, are routinely exposed by OS, orchestrators, and standard monitoring frameworks.

7.4 Measure Observability Measure observability in a DCCS goes beyond simply watching dashboards and it means understanding why the system behaves the way it does. When the internal processes and interactions of a distributed system are transparent and explainable, operators can move from reactive firefighting to proactive tuning: monitoring in real time, diagnosing root causes across cloud, edge, and IoT layers, and continuously improving performance. In short, explainability turns raw telemetry into actionable insight, keeping complex, heterogeneous, and increasingly autonomous systems accountable and adaptable. 52

To quantify this property, we define an observability score that combines two complementary ideas: how well each individual node can explain its own decisions, and how consistently cause-and-effect relationships flow between nodes. Formally:

PN E=

i i=1 γi Elocal · N

P 1−

i̸=j |CIij − CIji |

P

i,j CIij

! ,

(192)

i where N is the total number of nodes, Elocal is the local explainability score of node i, and γi is its associated weight. CIij captures the causal influence that node i exerts on node j , estimated through techniques such as Granger causality or other causal inference methods [94]. The first factor gives the weighted-average explainability across the system. The second factor penalises the score whenever inter-node causal relationships are asymmetric or poorly understood which reflects the intuition that a truly observable system should exhibit clear, consistent cause-and-effect links between its components. The minimal acquisition scope is Full System because observability depends on both the explainability of individual nodes and the causal relationships between components throughout the entire distributed system. The acquisition occurs during the Experimental phase because observability is primarily evaluated to assess and improve the design of monitoring and telemetry strategies rather than to monitor normal system operation. The acquisition method is Experimental Instrumentation because estimating explainability and causal relationships requires advanced analysis techniques, such as causal inference or explainable AI methods, which are not provided by standard telemetry.

7.5 Adaptivity Quotient Adaptivity quotient is a metric designed to quantify how effectively and rapidly a DCC system can sense, respond to, and recover from changes or disruptions across the continuum (i.e., fluctuating workloads, node failures, shifting network conditions). As recent research introduces adaptive frameworks, the ability to adapt is crucial for ensuring service continuity, meeting application requirements, and optimizing resource use across the continuum. This metric is mathematically defined as shown in Eq.(193). K

1 X Q= K

k=1

Pkpost 1 · Pkbase Tkadapt

! (193)

where, K represents the total number of adaptation events observed in DCC. Pkbefore is the metric (such as throughput or latency) before adaptation event k , and Pkafter is the metric after the system has adapted. Tk is the time taken to complete the adaptation for event k . The minimal acquisition scope is Full System because adaptivity emerges from the coordinated behavior of the entire DCCS before, during, and after adaptation events. The acquisition occurs during the Experimental phase because its purpose is to compare different adaptation strategies, or configurations, under controlled conditions in order to identify the most effective design. The acquisition method depends 53

on the performance metric used to evaluate the adaptation. Metrics such as throughput, latency, or resource utilization can be obtained through Standard Telemetry *, whereas application-specific or derived performance indicators may require Custom Instrumentation or even Experimental Instrumentation .

7.6 Maintain Equilibrium More hardware means better performance, but also higher bills, greater energy use (on track to consume 7% of global power by 2030 [95]), and a larger environmental footprint. Every gain in QoS through replication, caching, or indexing carries a corresponding rise in cost and resource consumption; cut back, and reliability drops. This creates a feedback loop that is hard to escape. For instance, increasing replication factors to improve data availability demands additional storage and processing power, while low-latency techniques like indexing and caching require more computational resources. Conversely, reducing computational power or storage capacity affects QoS which creates a self-perpetuating challenge, such as more resources improve performance but increase costs. On the other side, cost-cutting compromises system reliability. These investments raise the question of how effectively increased resources translate into real-world performance gains. Notably, the growth of personalized LLMs may not require such large computing environments but necessitates careful control over infrastructure due to the associated costs, especially for small organizations (e.g., universities or public services). For example, Amdahl’s Law (Eq. (13), where the variable S represents speedup and F represents fraction), which predicted this situation [96], highlights the limitation of diminishing returns: performance gains are constrained by the fraction of the workload that remains unoptimized. Therefore, the challenge for large-scale AI infrastructure initiatives lies not just in scaling hardware, but in efficiently using available resources to maximize QoS. The interplay between Cost (Cost), Resources (R), and QoS (Q) creates a complex optimization challenge. Increasing resources enhances QoS but raises costs, while reducing costs can degrade performance. Eq. (194) formalizes this trade-off, aiming QoS while adhering to cost and resource constraints. max Q(R, Cost) subjected to: Cost ≤ Costmax , R ≥ Rmin

R,Cost

(194)

Current management approaches (i.e., predominantly static provisioning or reactive autoscaling) struggle to maintain this balance under volatile workloads. Closing the gap will require AI-driven, self-optimising frameworks that learn from ongoing system fluctuations and continuously steer the infrastructure toward a near-optimal equilibrium across all three dimensions of Eq. (194). The minimal acquisition scope is Full System because equilibrium depends on the interaction between all resources and services across the DCCS. The acquisition occurs during the Experimental phase because the metric is intended to compare different architectures, orchestration strategies, or resource management policies under controlled workloads in order to identify the best trade-off between QoS, cost, and resource utilization. The acquisition method is Experimental Instrumentation because it 54

requires combining heterogeneous metrics (e.g., QoS, cost, and resource usage) into an optimization model that is not directly available through standard telemetry.

7.7 Data Locality Index In DCCS, tasks should ideally be executed close to the data source to reduce latency, bandwidth consumption, and privacy risks. A data locality index measures how close the execution node is to the data-producing node. Let src(Ti ) denote the source node that generates the data for task Ti , and let exec(Ti ) denote the node where the task is executed. The data locality index can be defined as:

DLI = 1 −

1 X dist(src(Ti ), exec(Ti )) , |T | distmax

(195)

Ti ∈T

where dist(src(Ti ), exec(Ti )) denotes the network, geographical, or hop-distance between the source and execution node, and distmax is the maximum possible distance in S . A higher DLI indicates better locality-aware execution. This metric is important because computing continuum applications often aim to reduce cloud dependency by processing data closer to IoT, mobile, edge, and fog nodes. The minimal acquisition scope is Multi-Node because computing the locality of a task requires information from both the data source node and the execution node. The acquisition occurs during the Operational phase in order to support locality-aware scheduling and task placement decisions that reduce communication latency, bandwidth consumption, and unnecessary data transfers. The acquisition method is Standard Telemetry because task placement, node identities, and network topology or routing information are routinely available through operating systems, orchestrators, and standard monitoring frameworks.

7.8 Continuum Fragmentation Index As discussed before, DCC resources are distributed across cloud, fog, edge, mobile, and IoT layers. Even when the overall amount of free resources is sufficient, these resources may be fragmented across many nodes. This fragmentation can make it difficult to place large tasks, deploy service chains, or allocate workloads that require a minimum amount of capacity on the same node or within the same layer. P f ree Let Rjf ree denote the free resource capacity of node j , and let Rftotal ree = j∈N Rj represent the total free resource capacity across all nodes in the continuum. The Continuum Fragmentation Index can be defined as

CF I = 1 −

maxj∈N Rjf ree

Rftotal ree

.

(196)

A higher CF I indicates higher fragmentation. This means that free resources exist in the DCC, but they are scattered across multiple nodes and may be difficult to use for placing large tasks or services. A lower CF I indicates that the available resources are more consolidated, making task placement easier. When CF I = 0, all free 55

resources are concentrated in a single node. As CF I approaches 1, the free resources become increasingly distributed across many nodes. The minimal acquisition scope is Full System because fragmentation depends on the distribution of free resources across all participating nodes. The acquisition occurs during the Operational phase in order to identify resource fragmentation that may affect task placement during system execution. The acquisition method is Standard Telemetry because the required resource availability metrics are routinely exposed by OS, virtualization platforms, and orchestration frameworks.

7.9 Migration Stability Index In DCCS, tasks and services may migrate among cloud, fog, edge, and mobile nodes. However, excessive migration can increase overhead, instability, and service disruption. A migration stability index measures whether the system adapts without unnecessary movement. Let Mk be the number of migrations during adaptation event k , and let Mkmax be the maximum acceptable number of migrations. The migration stability index can be defined as: K 1 X Mk M SI = 1 − . (197) K Mkmax k=1

A higher M SI indicates that the system maintains stability with fewer migrations, while a lower value indicates migration-heavy adaptation. The minimal acquisition scope is Full System because migration stability depends on the migration activity across the entire DCCS. The acquisition occurs during the Operational phase in order to detect excessive migration, and support more stable orchestration decisions during system execution. The acquisition method is Standard Telemetry because migration events are routinely recorded by virtualization platforms, container orchestrators, and resource management frameworks.

7.10 Adaptation Cost Efficiency Adaptation improves performance, but it also consumes resources, energy, and time. Therefore, it is useful to measure whether adaptation is worth its cost. For an adaptation event k , let ∆Pk denote the performance improvement after adaptation, and let Costadapt denote the total adaptation cost. The adaptation cost k efficiency can be defined as: 1 ACE = K

K X

∆Pk

adapt k=1 Costk

! .

(198)

The adaptation cost can include migration cost, energy cost, communication cost, and service interruption cost:

Costadapt = Costmig + Costeng + Costcomm + Costdown . k k k k k

(199)

A higher ACE indicates that the system achieves larger performance improvement with lower adaptation overhead. The minimal acquisition scope is Multi-Node 56

because both the adaptation benefits and their associated costs may involve multiple resources and services across the DCCS. The acquisition occurs during the Experimental phase because the metric is intended to compare different adaptation mechanisms or system configurations in order to identify the most cost-effective design under controlled conditions. The acquisition method is Experimental Instrumentation because it combines multiple heterogeneous metrics, such as migration, energy, communication, and service interruption costs, into a derived optimization metric that is not directly available through standard telemetry.

7.11 SLO Violation Recovery Time In DCCS, avoiding SLO violation is important, but recovering quickly after a violation is equally important. The SLO violation recovery time measures how long the system takes to return to an acceptable state after an SLO violation. Let tviol be the time when SLO violation k starts, and let trec be the time when k k the system returns to the acceptable SLO range. The average SLO recovery time is:

SRT =

K
1 X rec tk − tviol . k K

(200)

k=1

A lower SRT indicates faster recovery and stronger resilience. The minimal acquisition scope is Full App because SLOs are typically defined for applications, although system-level SLOs can also be specified. The acquisition occurs during the Operational phase because the metric enables SLO-aware applications and autonomic management frameworks to detect violations and evaluate how quickly the application returns to an acceptable operating state. The acquisition method is Experimental Instrumentation because, as discussed for the SLO compliance metric, it depends on an external SLO management component capable of defining SLOs, detecting violations, and identifying the recovery instant in addition to standard telemetry.

7.12 Carbon Efficiency per Useful Task A more application-aware metric is carbon efficiency (CO2 emissions) per useful task, which measures how many useful tasks are completed per unit carbon emission. Let CO2 (S ) denote the total carbon emission of the DCCS during ∆t. The carbon efficiency can be defined as: |T s | . (201) CEU T = CO2 (S ) For quality-aware applications, the metric can be extended as: P s Qi QCEU T = Ti ∈T . (202) CO2 (S ) A higher value means that the system produces more useful service output per unit carbon emission. The minimal acquisition scope is Full App because, although both useful tasks and CO2 emissions could be measured for a single computational node, 57

this metric evaluates the useful work produced by an application as a whole relative to its carbon footprint. The acquisition occurs during the Experimental phase because the metric is primarily intended to compare the sustainability of different application designs or deployment strategies. The acquisition method is Experimental Instrumentation because completed tasks require Custom Instrumentation , while CO2 emissions require Experimental Instrumentation . Consequently, the overall metric inherits the experimental acquisition method.

7.13 Water Usage Efficiency For large-scale DCCS involving cloud and data-center resources, water consumption is becoming an important sustainability metric because data centers use water for cooling. Water usage efficiency can be defined as:

WUE =

WS , ES

(203)

where WS is the total water consumed by the infrastructure and ES is the total energy consumed. A task-aware version can be defined as:

WPT =

WS , |T s |

(204)

where W P T denotes water consumption per successful task. The minimal acquisition scope is Full App because, although energy consumption and successful tasks can be measured for a single computational node, this metric evaluates the water efficiency of an application as a whole. The acquisition occurs during the Experimental phase because the metric is primarily intended to compare the sustainability of different application designs, deployment strategies, or execution environments. The acquisition method is Experimental Instrumentation because water consumption is generally not exposed by cloud providers or computing nodes through standard telemetry. Estimating the water footprint therefore requires provider-specific information or external estimation models, making novel instrumentation necessary.

7.14 Data Freshness or Age of Information In DCCS, especially for IoT, cyber-physical systems, digital twins, and real-time monitoring, it is not enough that data arrives; it must arrive while still fresh. Age of Information measures the freshness of received data or how up-to-date the information available in a DCCS is with respect to when it was originally generated. Let ui (t) denote the generation time of the most recently received update from source i at time t. The age of information is:

AoIi (t) = t − ui (t). 58

(205)

The average age of information is: 1 AoI = ∆t

Z t1 AoIi (t)dt.

(206)

t0

For DCCS, system-level freshness can be defined as: ρ

1 X AoI i FS = 1 − . ρ i=1 AoIimax

(207)

A higher freshness score indicates that the system maintains more up-to-date information from data-producing nodes. The minimal acquisition scope is Multi-Node because computing the age of information requires timestamps from both the dataproducing node and the node that receives or processes the update. The acquisition occurs during the Operational phase in order to detect stale information and support freshness-aware scheduling, monitoring, or control decisions during system execution. The acquisition method is Standard Telemetry because data generation and reception timestamps are routinely available through distributed tracing frameworks.

7.15 Trustworthiness Score In heterogeneous continuum environments, not all nodes may be equally trustworthy. Trustworthiness can combine reliability, security, privacy, availability, and historical behavior. For node j , a trustworthiness score can be defined as:

T Sj = α1 Rj + α2 Aj + α3 Secj + α4 P rivj + α5 Histj ,

(208)

where Rj is reliability, Aj is availability, Secj is security score, P rivj is privacy score, P5 and Histj is historical behavior score. The weights satisfy: r=1 αr = 1. The system-level trustworthiness score is:

T SS =

1 X T Sj . ζ

(209)

j∈N

The minimal acquisition scope is Single-Node because the trustworthiness score can be computed independently for each computational node, even though system-level trustworthiness can later be obtained by aggregation. The acquisition occurs during the Operational phase in order to support trust-aware scheduling and runtime decisions, allowing orchestration frameworks to avoid nodes with low trustworthiness. The acquisition method is Experimental Instrumentation because several of its components, such as security, privacy, or historical behavior scores, are not directly exposed through standard telemetry and typically require dedicated assessment mechanisms. 59

8 Conclusion Performance evaluation of DCCS requires a structured view of metrics because these systems combine heterogeneous computing, networking, storage, and sensing resources across cloud, fog, edge, mobile, IoT, and sensor layers. In this paper, we presented a taxonomy of performance metrics for DCCS and organized them into computing-level, network-level, and application/user-level categories. Instead of treating these metrics as independent measures, the taxonomy highlights how they collectively describe different aspects of continuum behavior, from task execution and resource usage to communication quality and application satisfaction. We also provided mathematical formulations for representative metrics to support clearer interpretation and more consistent comparison across different architectures, algorithms, and deployment scenarios. In addition, we discussed metric acquisition requirements in terms of acquisition scope, acquisition phase, and measurement method, which helps determine whether a metric should be collected from a single node, multiple nodes, or the full system, and whether it is better suited for operational monitoring or experimental evaluation. The paper further highlighted emerging dimensions such as sustainability, observability, adaptability, data locality, migration awareness, and continuum fragmentation, which reflect the evolving requirements of modern DCCS. The proposed taxonomy can serve as a practical reference for selecting suitable metrics according to the evaluation objective, application requirements, and deployment context. In future work, we will design computing continuum simulator that implement these metrics and use them to evaluate DCCS architectures and algorithms under realistic workload, mobility, resource, and network conditions.

Acknowledgment This research is partially funded by the European Union TALENTS (101299722), the Junta de Andalucı́a (Consejerı́a de Universidad, Investigación e Innovación) and co-funded by the EU through the FEDER Andalucı́a 2021-2027 Programme under project DGP PIDI 2024 00918, and also supported by CNS2023-144359 financed by MICIU/AEI/10.13039/501100011033 and the European Union NextGenerationEU/PRTR.

References [1] Casamayor Pujol, V., Donta, P.K., Morichetta, A., Murturi, I., Dustdar, S.: Distributed computing continuum systems–opportunities and research challenges. In: International Conference on Service-oriented Computing, pp. 405–407 (2022). Springer [2] Donta, P.K., Murturi, I., Casamayor Pujol, V., Sedlak, B., Dustdar, S.: Exploring the potential of distributed computing continuum systems. Computers 12(10), 198 (2023) 60

[3] Pujol, V.C., Donta, P.K., Morichetta, A., Murturi, I., Dustdar, S.: Edge intelligence—research opportunities for distributed computing continuum systems. IEEE Internet Computing 27(4), 53–74 (2023) https://doi.org/10.1109/MIC. 2023.3284693 [4] Buyya, R., Srirama, S.N., Casale, G., Calheiros, R., Simmhan, Y., Varghese, B., Gelenbe, E., Javadi, B., Vaquero, L.M., Netto, M.A., et al.: A manifesto for future generation cloud computing: Research directions for the next decade. ACM computing surveys (CSUR) 51(5), 1–38 (2018) [5] Hua, H., Li, Y., Wang, T., Dong, N., Li, W., Cao, J.: Edge computing with artificial intelligence: A machine learning perspective. ACM Computing Surveys 55(9), 1–35 (2023) [6] Dustdar, S., Murturi, I.: Towards distributed edge-based systems. In: 2020 IEEE Second International Conference on Cognitive Machine Intelligence (CogMI), pp. 1–9 (2020). https://doi.org/10.1109/CogMI50398.2020.00021 . IEEE [7] Dustdar, S., Murturi, I.: Towards iot processes on the edge. Next-Gen Digital Services. A Retrospective and Roadmap for Service Computing of the Future: Essays Dedicated to Michael Papazoglou on the Occasion of His 65th Birthday and His Retirement, 167–178 (2021) [8] Li, S., Xu, L.D., Zhao, S.: The internet of things: a survey. Information systems frontiers 17, 243–259 (2015) [9] Dustdar, S., Pujol, V.C., Donta, P.K.: On distributed computing continuum systems. IEEE Transactions on Knowledge and Data Engineering 35(4), 4092–4105 (2022) https://doi.org/10.1109/TKDE.2022.3142856 [10] Casamayor Pujol, V., Morichetta, A., Murturi, I., Kumar Donta, P., Dustdar, S.: Fundamental research challenges for distributed computing continuum systems. Information 14(3), 198 (2023) https://doi.org/10.3390/info14030198 [11] Rawlley, O., Gupta, S., Chandrakar, J., Johnson, M.K., Kalra, C.: Artificial intelligence inspired task offloading and resource orchestration in intelligent transportation systems. Cognitive Computation 17(1), 18 (2025) [12] Gong, T., Huang, S., Wang, Z., Yi, B., Kumari, S., Chen, C.M., Lv, J.: Intelligent orchestration of ai service chains in wireless edge networks. Computer Communications, 108504 (2026) [13] Fan, W., Yu, Y., Bao, C., Liu, Y.: Vehicular edge intelligence: Drl-based resource orchestration for task inference in vehicle-rsu-edge collaborative networks. IEEE Transactions on Mobile Computing 24(10), 10927–10944 (2025)

61

[14] Shahid, H.F., Akdemir, B., Islam, J., Ahmad, I., Harjula, E.: Iot service orchestration in edge-cloud continuum with 6g: A review. IEEE Internet of Things Journal (2026) [15] Kumar, B., Bhardwaj, A., Prasad Sahu, D.: Task offloading for cavs edge computing environment: Taxonomy, critical review, and future road map. ACM Computing Surveys 58(8), 1–35 (2026) [16] Mohajer, A., Mirzaei, A., Darabi, M., Fernando, X.: Joint sla-aware task offloading and adaptive service orchestration with graph-attentive multi-agent reinforcement learning. IEEE Transactions on Network and Service Management (2026) [17] Ren, Y., Yu, S., Guo, A.: Joint scheduling mechanism for dynamic slice resource allocation and task offloading in user-edge-cloud systems. IEEE Transactions on Cloud Computing 14(1), 276–292 (2026) https://doi.org/10.1109/TCC.2026. 3653217 [18] Salimi, R., Azizi, S., Shojafar, M.: Dynamic and resource-aware task scheduling in fog-cloud environments via an improved priority-aware genetic algorithm. Journal of Grid Computing 24(2), 5 (2026) [19] Ayouni, S., Sliti, M., Alosaimi, L.K., Maddeh, M.: Resource-aware edge–cloud continuum for lightweight wearable smart-healthcare analytics. Journal of Cloud Computing (2026) [20] Hua, K., Su, S., Wang, Y.: Intelligent service migration for the internet of vehicles in edge computing: A mobility-aware deep reinforcement learning framework. Computer Networks 257, 111021 (2025) [21] Liu, Y., Bi, Y., Liu, Y., Niyato, D., Yang, K., Zhao, L., Hawbani, A.: Service satisfaction-aware adaptive service migration and resource allocation in vehicular edge computing. IEEE Transactions on Mobile Computing (2025) [22] Du, A., Jia, J., Chen, J., Wang, X., Huang, M.: Online queue-aware service migration and resource allocation in mobile edge computing. IEEE Transactions on Vehicular Technology 74(5), 8063–8078 (2025) [23] Zeng, L., Zhang, C., Wang, Z., Du, H., Jia, X.: Towards collaborative and latencyaware microservice migration in mobile edge computing. IEEE Internet of Things Journal (2025) [24] Bozkaya-Aras, E.: Optimizing service migration in iot edge networks: Digital twin-based computation and energy-efficient approach. In: 2025 IEEE Wireless Communications and Networking Conference (WCNC), pp. 1–6 (2025). IEEE [25] Saleh, A., Donta, P.K., Morabito, R., Motlagh, N.H., Tarkoma, S., Lovén, L.:

62

Follow-me ai: Energy-efficient user interaction with smart environments. IEEE Pervasive Computing 24(1), 32–42 (2025) https://doi.org/10.1109/MPRV.2025. 3539421 [26] Wang, Y., Saleh, A., Donta, P.K., Hossein Motlagh, N., Lovén, L., Tarkoma, S., Dustdar, S.: ikafka: Intelligent storage management for adaptive event streaming in kafka. In: 2025 IEEE International Conference on Edge Computing and Communications (EDGE), pp. 34–43 (2025). https://doi.org/10.1109/EDGE67623. 2025.00013 [27] Saleh, A., Tarkoma, S., Donta, P.K., Lindgren, A., Motlagh, N.H., Dustdar, S., Pirttikangas, S., Lovén, L.: UserCentrix: An Agentic Memory-augmented AI Framework for Smart Spaces (2026) [28] Ye, P., Lapkovskis, A., Saleh, A., Zhang, Q., Donta, P.K.: NeSy-Edge: NeuroSymbolic Trustworthy Self-Healing in the Computing Continuum (2026) [29] Saleh, A., Tarkoma, S., Lindgren, A., Donta, P.K., Dustdar, S., Pirttikangas, S., Lovén, L.: Memindex: Agentic event-based distributed memory management for multi-agent systems. ACM Transactions on Autonomous and Adaptive Systems [30] Donta, P.K., Zhang, Q., Dustdar, S.: Performance measurements in the ai-centric computing continuum systems. In: 2025 IEEE 11th World Forum on Internet of Things (WF-IoT), pp. 1–6 (2025). https://doi.org/10.1109/WF-IoT64238.2025. 11270701 [31] Sedlak, B., Pujol, V.C., Donta, P.K., Dustdar, S.: Markov Blanket Composition of SLOs. In: 2024 IEEE International Conference on Edge Computing and Communications (EDGE), Shenzhen, China, pp. 128–138 (2024). https://doi.org/10. 1109/EDGE62653.2024.00025 [32] Kant, K.: Introduction to Computer System Performance Evaluation. International Edition, ??? (1992) [33] Casamayor Pujol, V., Sedlak, B., Xu, Y., Donta, P.K., Dustdar, S.: DeepSLOs for the Computing Continuum. In: Proceedings of the 2024 Workshop on Advanced Tools, Programming Languages, and PLatforms for Implementing and Evaluating Algorithms for Distributed systems. ApPLIED’24, pp. 1–10. Association for Computing Machinery, New York, NY, USA (2024). https://doi.org/10.1145/ 3663338.3663681 [34] Cao, Y.: Better Orchestration for SLO-Oriented Cross-site Microservices in Multi-tenant Cloud/Edge Continuum. In: Proceedings of the 24th International Middleware Conference, New York, USA (2023). https://doi.org/10.1145/ 3626564.3629091

63

[35] Lu, S., Wu, J., Lu, P., Wang, N., Liu, H., Fang, J.: QoS-Aware Online Service Provisioning and Updating in Cost-Efficient Multi-Tenant Mobile Edge Computing. IEEE Transactions on Services Computing 17(1), 113–126 (2024) https://doi.org/10.1109/TSC.2023.3335412 [36] Čilić, I., Krivić, P., Podnar Žarko, I., Kušek, M.: Performance Evaluation of Container Orchestration Tools in Edge Computing Environments. Sensors 23(8), 4008 (2023) https://doi.org/10.3390/s23084008 [37] Herrera, J.L., Sedlak, B., Dustdar, S.: Active Inference for Sustainable Computing Continuum Systems. IEEE Internet Computing 30(1), 81–90 (2026) https://doi. org/10.1109/MIC.2025.3590621 [38] Lilja, D.J.: Measuring Computer Performance: a Practitioner’s Guide. Cambridge university press, ??? (2005) [39] Cheikhrouhou, O.: Secure group communication in wireless sensor networks: a survey. Journal of Network and Computer Applications 61, 115–132 (2016) [40] Kumar, D.P., Amgoth, T., Annavarapu, C.S.R.: Machine learning algorithms for wireless sensor networks: A survey. Information Fusion 49, 1–25 (2019) https: //doi.org/10.1016/j.inffus.2018.09.013 [41] Hong, C.-H., Varghese, B.: Resource management in fog/edge computing: a survey on architectures, infrastructure, and algorithms. ACM Computing Surveys (CSUR) 52(5), 1–37 (2019) [42] Donta, P.K., Monteiro, E., Dehury, C.K., Murturi, I.: Learning-driven ubiquitous mobile edge computing:: Network management challenges for future generation Internet of Things (2023) [43] Wang, X., Li, J., Ning, Z., Song, Q., Guo, L., Guo, S., Obaidat, M.S.: Wireless powered mobile edge computing networks: A survey. ACM Computing Surveys (2023) https://doi.org/10.1145/3579992 [44] Mao, Y., You, C., Zhang, J., Huang, K., Letaief, K.B.: A survey on mobile edge computing: The communication perspective. IEEE Communications Surveys & Tutorials 19(4), 2322–2358 (2017) https://doi.org/10.1109/COMST.2017. 2745201 [45] Jo, A.: The promise and peril of generative ai. Nature 614(1), 214–216 (2023) [46] Baidoo-Anu, D., Ansah, L.O.: Education in the era of generative artificial intelligence (ai): Understanding the potential benefits of chatgpt in promoting teaching and learning. Journal of AI 7(1), 52–62 (2023) [47] Thirunavukarasu, A.J., Ting, D.S.J., Elangovan, K., Gutierrez, L., Tan, T.F.,

64

Ting, D.S.W.: Large language models in medicine. Nature medicine, 1–11 (2023) [48] Kasneci, E., Seßler, K., Küchemann, S., Bannert, M., Dementieva, D., Fischer, F., Gasser, U., Groh, G., Günnemann, S., Hüllermeier, E., et al.: Chatgpt for good? on opportunities and challenges of large language models for education. Learning and individual differences 103, 102274 (2023) [49] Chaintreau, A., De Vleeschauwer, D.: A closed form formula for long-lived tcp connections throughput. Performance Evaluation 49(1), 57–76 (2002) https:// doi.org/10.1016/S0166-5316(02)00131-1 . Performance 2002 [50] Aczél, J., Ertel, W.: A new formula for speedup and its characterization. Acta Informatica 34(8), 637–652 (1997) [51] Amdahl, G.M.: Validity of the single processor approach to achieving large scale computing capabilities. In: Proceedings of the April 18-20, 1967, Spring Joint Computer Conference. AFIPS ’67 (Spring), pp. 483–485. ACM, New York, NY, USA (1967). https://doi.org/10.1145/1465482.1465560 [52] Gustafson, J.L.: Reevaluating amdahl’s law. Commun. ACM 31(5), 532–533 (1988) https://doi.org/10.1145/42411.42415 [53] Alexander, B.D., Simsick, J.L., Dillon, R.A., Giedt, J.W., Mellott, M.M., Wiles, J.E., Olson, T.L.: System and method for application resource utilization metering and cost allocation in a utility computing environment. Google Patents. US Patent 7,499,968 (2009) [54] Murturi, I., Sedlak, B., Farahani, R., Dustdar, S.: Performance evaluation of privacy models for data streams on the edge. Internet Technology Letters 9(3), 70250 (2026) [55] Shipman, G.M., Brightwell, R., Barrett, B., Squyres, J.M., Bloch, G.: Investigations on infiniband: Efficient network buffer utilization at scale. In: European Parallel Virtual Machine/Message Passing Interface Users’ Group Meeting, pp. 178–186 (2007). Springer [56] Beltrán, M.: Defining an elasticity metric for cloud computing environments. EAI Endorsed Transactions on Cloud Systems 2(5), 172 (2016) [57] Al-Dhuraibi, Y., Paraiso, F., Djarallah, N., Merle, P.: Elasticity in cloud computing: State of the art and research challenges. IEEE Transactions on Services Computing 11(2), 430–447 (2018) https://doi.org/10.1109/TSC.2017.2711009 [58] Herbst, N.R., Kounev, S., Reussner, R.: Elasticity in cloud computing: What it is, and what it is not. In: 10th International Conference on Autonomic Computing (ICAC 13), pp. 23–27 (2013)

65

[59] Murturi, I., Dustdar, S.: Decent: A decentralized configurator for controlling elasticity in dynamic edge networks. ACM Transactions on Internet Technology (TOIT) 22(3), 1–21 (2022) [60] Sedlak, B., Pujol, V.C., Donta, P.K., Dustdar, S.: Equilibrium in the computing continuum through active inference. Future Generation Computer Systems 160, 92–108 (2024) [61] Muralidhar, R., Borovica-Gajic, R., Buyya, R.: Energy efficient computing systems: Architectures, abstractions and modeling to techniques and standards. ACM Computing Surveys (CSUR) 54(11s), 1–37 (2022) [62] Rong, H., Zhang, H., Xiao, S., Li, C., Hu, C.: Optimizing energy consumption for data centers. Renewable and Sustainable Energy Reviews 58, 674–691 (2016) [63] Prieto, A., Prieto, B., Escobar, J.J., Lampert, T.: Evolution of computing energy efficiency: Koomey’s law revisited. Cluster Computing 28(1), 42 (2025) [64] Alsharif, M.H., Jahid, A., Kannadasan, R., Singla, M.K., Gupta, J., Nisar, K.S., Abdel-Aty, A.-H., Kim, M.-K.: Survey of energy-efficient fog computing: Techniques and recent advances. Energy Reports 13, 1739–1763 (2025) [65] Govori, E., Murturi, I., Dustdar, S.: A comprehensive performance evaluation of procedural geometry workloads on resource-constrained devices. In: 2023 IEEE International Conference on Edge Computing and Communications (EDGE), pp. 271–279 (2023). IEEE [66] Donta, P.K., Rao, B.S.P., Amgoth, T., Annavarapu, C.S.R., Swain, S.: Data collection and path determination strategies for mobile sink in 3d wsns. IEEE Sensors Journal 20(4), 2224–2233 (2020) https://doi.org/10.1109/JSEN.2019.2949146 [67] Otero, M., Garcı́a, J.M., Fernandez, P.: An extensible lightweight framework for distributed telemetry of microservices. Sustainable Computing: Informatics and Systems 46, 101100 (2025) https://doi.org/10.1016/j.suscom.2025.101100 [68] Lamport, L.: Specifying concurrent program modules. ACM Trans. Program. Lang. Syst. 5(2), 190–222 (1983) https://doi.org/10.1145/69624.357207 [69] Lamport, L.: Concurrent Algorithms, 1st edn., pp. ciation for Computing Machinery, New York, NY, https://doi.org/10.1145/3544585.3544591

47–80. AssoUSA (2022).

[70] Lamport, L.: Turing lecturethe computer science of concurrency: the early years. Commun. ACM 58(6), 71–76 (2015) https://doi.org/10.1145/2771951 [71] Chen, Q., Song, X., Song, T., Yang, Y.: Vehicular edge computing networks

66

optimization via drl-based communication resource allocation and load balancing. IEEE Transactions on Mobile Computing 24(9), 9222–9237 (2025) https: //doi.org/10.1109/TMC.2025.3559707 [72] Jain, R., Chiu, D., Hawe, W.: A Quantitative Measure Of Fairness And Discrimination For Resource Allocation In Shared Computer Systems (1998) [73] Murturi, I., Dehury, C.K., Monteiro, E., Donta, P.K.: Intelligent Ubiquitous Mobile Edge Network Management. Wiley Online Library (2026) [74] Link, C.A., Im, H.: Method and system for peer-to-peer network latency measurement. Google Patents. US Patent 6,012,096 (2000) [75] Hansson, T., Donta, P.K.: Predictive RTO for CoAP using Lightweight Support Vector Regression in Internet of Things (2026). https://arxiv.org/abs/2607.18273 [76] Demichelis, C., Chimento, P.: IP Packet Delay Variation Metric for IP Performance Metrics. RFC 3393 (2002). https://doi.org/10.17487/RFC3393 [77] Prasad, R., Dovrolis, C., Murray, M., Claffy, K.: Bandwidth estimation: metrics, measurement techniques, and tools. IEEE network 17(6), 27–35 (2003) [78] Sommers, J., Barford, P., Duffield, N., Ron, A.: A geometric approach to improving active packet loss measurement. IEEE/ACM Transactions on Networking 16(2), 307–320 (2008) https://doi.org/10.1109/TNET.2007.900412 [79] Persico, V., Marchetta, P., Botta, A., Pescapè, A.: Measuring network throughput in the cloud: The case of amazon ec2. Computer Networks 93, 408–422 (2015) [80] Xie, H., Zhang, C., Luo, P., Zhang, Z., Yang, G., Zhang, X., Soong, B.-H.: Risk-aware safe throughput forecasting for starlink networks. arXiv preprint arXiv:2605.09508 (2026) [81] Basney, J., Livny, M.: Improving goodput by coscheduling cpu and network capacity. The International Journal of High Performance Computing Applications 13(3), 220–230 (1999) [82] Wongpanich, A., Oguntebi, T., Paredes, J.B., Wang, Y.E., Phothilimthana, P.M., Mitra, R., Zhou, Z., Kumar, N., Reddi, V.J.: Machine learning fleet efficiency: Analyzing and optimizing large-scale google tpu systems with ml productivity goodput. arXiv preprint arXiv:2502.06982 (2025) [83] Salvatori, M., Vannella, F., Macaluso, S., Trevlakis, S.E., Perales, C.S., SuarezVarela, J., Boulogeorgos, A.-A.A., Arapakis, I.: Dual-Graph Multi-Agent Reinforcement Learning for Handover Optimization (2026) [84] Saleh, A., Morabito, R., Tarkoma, S., Lindgren, A., Pirttikangas, S., Lovén, L.:

67

Agentic tinyml for intent-aware handover in 6g wireless networks. IEEE Wireless Communications 33(2), 65–74 (2026) https://doi.org/10.1109/MWC.2025. 3635579 [85] Feng, D., Jiang, C., Lim, G., Cimini, L.J., Feng, G., Li, G.Y.: A survey of energyefficient wireless communications. IEEE Communications Surveys & Tutorials 15(1), 167–178 (2012) [86] Luo, H., Sun, G., Chi, C., Yu, H., Guizani, M.: Convergence of symbiotic communications and blockchain for sustainable and trustworthy 6g wireless networks. IEEE Wireless Communications 32(2), 18–25 (2025) https://doi.org/10.1109/ MWC.001.2400245 [87] Sedlak, B., Pujol, V.C., Abril, I.M., Donta, P.K., Toosi, A.N., Dustdar, S.: Service Orchestration in the Computing Continuum: Structural Challenges and Vision. IEEE Internet Computing 30(2), 88–98 (2026) https://doi.org/10.1109/MIC. 2026.3662064 [88] Lovén, L., Saleh, A., Farahani, R., Murturi, I., López, M.B., Donta, P.K., Dustdar, S.: Real-Time AI Service Economy: A Framework for Agentic Computing Across the Continuum (2026) [89] Hao, M., Tian, X., Yang, S., Yang, H., He, H., Li, X., Wang, Y., Liu, Z., Wang, D., Zhang, W.: Greendls: An energy-efficient and slo-aware deep learning serving system. IEEE Transactions on Computers 75(8), 2687–2701 (2026) https://doi. org/10.1109/TC.2025.3642827 [90] Fresno-Aranda, R., Ojeda-Perez, J.S., Fernandez, P., Ruiz-Cortes, A.: Governify. an agreement-based service governance framework. Software Impacts 19, 100629 (2024) https://doi.org/10.1016/j.simpa.2024.100629 [91] Vahdat, A., Ma, X., Patterson, D.: New computer evaluation metrics for a changing world. Communications of the ACM 67(10), 31–33 (2024) [92] Winterton, R.: Newton’s law of cooling. Contemporary Physics 40(3), 205–212 (1999) [93] Jain, R., Durresi, A., Babic, G.: Throughput fairness index: An explanation. In: ATM Forum Contribution, vol. 99, pp. 1–13 (1999) [94] Pujol, V.C., Sedlak, B., Donta, P.K., Dustdar, S.: On causality in distributed continuum systems. IEEE Internet Computing 28(2), 57–64 (2024) [95] Chen, S.: Data centres will use twice as much energy by 2030-driven by ai. Nature (2025) https://doi.org/10.1038/d41586-025-01113-z

68

[96] Amdahl, G.M.: Computer architecture and Amdahl’s law. Computer 46(12), 38– 46 (2013)

69