A Multidimensional Elasticity Framework for Adaptive Data Analytics Management in the Computing Continuum

Ilir Murturi; Juan Luis Herrera; Juan M. Murillo; Pantelis Frangoudis; Schahram Dustdar; Sergio Laso

REVIEW 4 major objections 5 minor 15 references

A Multidimensional Elasticity Framework for Adaptive Data Analytics Management in the Computing Continuum

T0 review · 4 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A multidimensional elasticity framework lets an RL-based orchestrator adapt both infrastructure resources and data analytics requirements (coverage, sample, freshness) so analytics can continue even when resources cannot scale.

desk verdict A clearly written elasticity framework with a real gap: the RL orchestrator adapts sample and freshness but not coverage, despite the abstract's multidimensional claim. read the letter →

arxiv 2501.11369 v1 pith:WMJRRNE4 submitted 2025-01-20 cs.DC

Sergio Laso , Ilir Murturi , Pantelis Frangoudis , Juan Luis Herrera , Juan M. Murillo , Schahram Dustdar This is my paper · ORCID

classification cs.DC

keywords multidimensionalelasticitycomputingcontinuumQ-learningorchestratordataanalyticsrequirementsSLOfulfillmentedgeresourceadaptationsmartcities

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper proposes a management framework for computing continuum systems (IoT-edge-cloud) that treats data analytics requirements—coverage, sample, and freshness—as elastic dimensions alongside CPU, memory, bandwidth, and cost. The central claim is that an orchestrator driven by Q-learning can, at runtime, choose adjustments to both the analytics configuration and the allocated compute capacity so that service-level objectives are met even when the infrastructure cannot simply scale up. If correct, this gives operators a way to keep analytics useful during resource bottlenecks by deliberately degrading less-critical analytics qualities rather than letting the system fail. Experiments on a smart-city heatmap testbed and simulations of a four-node environment show the impact of these requirements on CPU usage and that the RL agent can prioritize whichever SLO the operator weights most heavily.

What carries the argument

The load-bearing mechanism is a tabular Q-learning agent embedded in an orchestrator with two monitors: the Architecture Monitor tracks resource dimensions and the Analytics Monitor tracks consumer requirements. The state space is a discretized combination of a binary CPU-utilization flag (overloaded or not), the allocated compute capacity level, and the analytics configuration levels (freshness and sample size); the action space likewise selects a capacity level and an analytics configuration. The reward function is the sum of fixed positive or negative contributions for each SLO (CPU, cost, freshness, sample), making the learned policy directly reflect operator priorities. The framework also spells out explicit relationships between requirements and architecture dimensions (coverage maps to active node count, sample to data volume, freshness to refresh rate), which are used to explain the measured CPU effects and guide the adaptation space.

What would settle it

Run the trained Q-learning policy on a deployment where nodes have unequal processing capacities and uneven data sources; if SLO fulfillment degrades significantly below the reported 95–98% balanced ratios, or the agent repeatedly overloads the slower nodes, the identical-node simplification is falsified. Alternatively, remove a node during operation and observe whether the policy recovers without retraining.

Watch

Extended reading notes

Core claim

The paper's contribution is a framework in which elasticity applies not only to infrastructure (CPU, memory, bandwidth) but also to the data analytics application's own requirements. The discovery is that a Q-learning agent can learn a policy that interleaves two kinds of actions: scaling resources (changing the number of application instances or capacity) and degrading or restoring analytics requirements (freshness and sample size; coverage is left out of the RL instantiation). Under each state defined by CPU utilization level, allocated capacity, and analytics configuration, the agent receives a reward for each SLO met; tuning reward weights steers the resulting behavior, for example prioritizing freshness at the expense of cost. The evaluation shows the agent can maintain near-100% fulfillment of a prioritized SLO when that SLO's reward weight is dominant, while a balanced reward weighting yields roughly 95–98% fulfillment across CPU, freshness, sample, and cost SLOs.

Load-bearing premise

The learning agent assumes all compute nodes are identical in capacity and allocation and treats the whole system as over-utilized if any single node is overloaded, so the learned policy may fail on heterogeneous real-world infrastructures.

Editorial extensions

If this is right

Operators can encode SLO priorities as reward weights and obtain a runtime controller that automatically trades analytics quality for resource headroom, without needing an explicit model of the environment.
Because coverage, sample, and freshness each have distinct CPU load signatures (stepwise, gradual, and periodic-spiky), a controller that only scales resources cannot match the flexibility of also adapting these analytics requirements.
The Q-learning agent converges on a coarse discretized state and action space, suggesting that practical deployments do not require high-resolution state representations to achieve balanced SLO fulfillment around 95–98%.
The current RL instantiation omits coverage, so the framework as evaluated would need state and action extensions before it can manage geo-distributed deployments where coverage is a primary lever.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The same reward-shaping approach could naturally extend to multi-objective or constrained RL to handle heterogeneous nodes, which the paper's identical-node assumption currently prevents.
A stress test with unequal node capacities and uneven data-source distributions would likely expose the binary CPU-utilization state's limitation, as the agent cannot pinpoint the bottleneck node.
Comparing the learned policy to a simple threshold-based heuristic would clarify how much of the benefit comes from RL rather than from the elasticity framework itself, a comparison the paper does not report.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The paper is a modest but legitimate extension of the authors' prior quality-elasticity work: they add a Q-learning orchestrator that jointly adjusts resource allocation and two analytics requirements (sample size and freshness), with cost folded into the resource dimension. The testbed experiments usefully show that coverage, sample, and freshness all affect CPU usage in the expected directions, and the simulation demonstrates that hand-set reward weights can steer SLO priorities. The writing is clear and the limitations are mostly stated openly.

The main problem is the coverage gap. The abstract and introduction claim the framework adaptively modulates coverage, sample, and freshness, but the RL agent's state and action spaces, described in Section III-D3b, only include freshness and sample size. The paper explicitly says "in this instantiation of the QL agent, we do not consider analytics coverage." Coverage appears only as a manually varied parameter in the testbed, never as an orchestrator action. So the central "multidimensional" claim overstates what is implemented. This is not a nitpick; it is the advertised contribution.

The evaluation is otherwise thin but not dishonest. The testbed has one head node and three edge nodes with no repetition or error bars, so the CPU curves are qualitative. The RL simulation lacks baselines (random or heuristic policies), and Table I largely reflects the reward weights rather than an independent finding. The system model also assumes identical nodes and binary overload state, which limits transferability. These are weaknesses, but they are the usual kind of proof-of-concept gaps, not fatal flaws.

The paper would benefit from aligning the claims with the actual implementation, adding baselines and basic statistics, and either extending the agent to handle coverage or explicitly scoping the contribution to sample and freshness. I would send it to peer review, because the framework is plausible, the gap is fixable in revision, and the subfield could use more concrete orchestrator designs. I would not cite it in my own work until the coverage issue is resolved.

Referee Report

4 major / 5 minor

Summary. The paper proposes a multidimensional elasticity framework for data analytics in the computing continuum. It distinguishes data analytics requirements (coverage, sample, freshness, response time, cost) from infrastructure dimensions (computing nodes, network, data) and presents an orchestrator whose decision-making is driven by a Q-learning agent. The agent is intended to adapt both resource allocations and analytics configurations to meet SLOs. The evaluation has two parts: testbed experiments on a head node and three edge nodes measuring the CPU impact of varying coverage, sample, and freshness; and a simulation study reporting SLO fulfillment ratios under different reward configurations for the Q-learning predictor.

Significance. If fully realized, the framework would make a useful contribution by letting continuum systems automatically trade analytics quality (coverage, sample, freshness) for resource headroom and cost. The paper provides a clear categorization of analytics-related elasticity dimensions, a concrete Q-learning orchestrator design, and an explicit reward formulation tied to SLOs. The testbed measurements give a qualitative demonstration that analytics requirements affect CPU usage, and the authors are transparent about several modeling simplifications. However, the implemented RL agent omits coverage, the evaluation is preliminary (single small testbed, no baseline comparison, no statistical rigor), and the RL results largely reflect the hand-set reward structure. The significance as demonstrated is therefore moderate, although the architectural idea is promising.

major comments (4)

[§III-D3b, §IV-E, Abstract] The abstract and §I claim that the orchestrator dynamically adjusts data analytics requirements 'including coverage, sample, and freshness,' but the Q-learning agent's state and action spaces encode only freshness and sample size, and the paper explicitly states 'we do not consider analytics coverage.' Table I reports no coverage SLO, and Fig. 4 adapts only sample and freshness. Coverage appears in Fig. 3a only as a manually varied testbed parameter. Thus the central 'multidimensional' claim overstates what is implemented and evaluated; the framework currently adapts two analytics requirements plus resource/cost dimensions, not the three named requirements.
[§III-D3c, Table I] The reward weights in §III-D3c are hand-set to prioritize specific SLOs (e.g., rf = 10 with other weights set to 1), and Table I then reports that the prioritized SLO is fulfilled close to 100% of the time. This outcome is largely a consequence of the reward design rather than an independent prediction of the framework's effectiveness. The experiment demonstrates that the Q-learning agent can optimize a given reward, but it does not validate the framework's ability to balance requirements in a realistic setting. A baseline (e.g., a greedy policy, a random policy, or an offline heuristic) and a convergence analysis would make the decision-making claim more substantive.
[§IV-E] The simulation model is only partially specified: the overload transition probability is mentioned but not given, the data intensity distribution is not defined, and the mapping from capacity levels to cost is described only qualitatively. No error bars, confidence intervals, or multiple-seed results are reported for the SLO fulfillment ratios. As a result, the numbers in Table I cannot be reproduced or assessed for statistical significance, and the claimed superiority of the balanced reward configuration is not supported by any comparison to alternative policies.
[§III-D3b, §IV] The state space assumes that all compute nodes and application instances are identical and that CPU utilization is binary (overloaded or not, if any node is overloaded). This simplification prevents the agent from learning to target a bottleneck node, and the policy may not transfer to heterogeneous continuum deployments where nodes differ in capacity, cost, and location. The authors acknowledge this simplification, but the evaluation does not test robustness to node heterogeneity, which is central to the 'computing continuum' setting described in §I.

minor comments (5)

[§III-A] Response Time and Cost are listed as data analytics requirements, but they do not appear in the RL state/action spaces or in the evaluation; clarify how these requirements are meant to be handled by the orchestrator.
[§IV-C] The testbed measurements in Figs. 3a-c appear to be single runs; adding error bars or repeated-run statistics would make the reported trends more convincing.
[§IV-E] The description of the Q-learning setup omits the learning rate, discount factor, exploration strategy, and convergence criterion; specifying these would improve reproducibility.
[References] The paper says it uses 'the One simulator' to generate the person movement dataset, but reference [15] is titled 'Oppnets and rural areas: an opportunistic solution for remote communications'; please verify the citation and provide the correct reference for the ONE (Opportunistic Network Environment) simulator.
[Table I] The reward structure notation '(rCP U: rf : rs : rc)' is not defined in the table caption; adding a one-line definition would improve readability.

Circularity Check

1 steps flagged · score 4.0 of 10

The SLO-fulfillment table largely restates the hand-tuned reward function by construction, while the claimed adaptive coverage dimension is absent from the implemented QL agent.

self definitional [Section III-D3c (Reward structure); Section IV-E (RL-based predictor performance) and Table I.]
"This design provides flexibility to prioritize different operator preferences by tuning these amounts. For example, in our evaluation, we set rf = 10 and rCPU = rc = rs = 1 to drive our QL agent towards actions that favor SLOf fulfillment, potentially at the expense of other SLO violations. ... As Table I shows, when the relative importance of a specific SLO is high (e.g., when freshness matters more, the rf reward component is 10x higher than the other components), the QL-based predictor fulfills this SLO close to 100% of the time, while other SLOs may suffer."

The reward function is defined as a weighted sum of indicators of whether each SLO is met, with the weights hand-set by the operator. Q-learning is trained to maximize cumulative reward, so the 'SLO fulfillment ratio' reported in Table I is the very objective being optimized. A high fulfillment ratio for the SLO carrying the largest reward weight is therefore a definitional consequence of the reward design (given convergence), not an independent empirical finding about the framework's effectiveness. The testbed measurements of Section IV-C (Fig. 3) independently ground the relationships between analytics requirements and CPU usage, so the circularity is partial and confined to the RL evaluation; the central resource-impact claims do not reduce to the reward.

full rationale

The paper's central derivation chain is mostly self-contained: the testbed experiments in Section IV-C measure the impact of coverage, sample, and freshness on CPU usage, and the adaptation example in Fig. 4 demonstrates the orchestrator adjusting sample and freshness. Those results do not reduce to the RL reward by construction. The principal circular element is the RL evaluation in Section IV-E: because the reward is a weighted sum of SLO-satisfaction indicators, Table I's finding that the prioritized SLO is fulfilled near 100% of the time is essentially a restatement of the optimization objective, not an independent prediction. Separately, the abstract and introduction claim the orchestrator adapts 'coverage, sample, and freshness,' but Section III-D3b explicitly states 'in this instantiation of the QL agent, we do not consider analytics coverage,' so the coverage-adaptation claim is an implementation gap rather than a circularity. That gap does not by itself raise the circularity score, but it is a material overstatement of the demonstrated contribution. Overall, the partial circularity in the SLO evaluation and the unsupported coverage claim warrant a moderate score of 4.

Assumptions & free parameters 4 free parameters · 5 assumptions · 0 invented entities

The central claim rests on a handful of hand-chosen simulation parameters, most notably reward weights that directly encode the priorities the evaluation then reports as fulfilled. The testbed part is more independent, but the overall evidence is thin and the strongest results in Table I follow largely from the reward design.

free parameters (4)

Reward weights r_CPU, rf, rs, rc = 10:1:1:1, 1:10:1:1, 1:1:10:1, 1:1:1:10, 1:1:1:1 (Table I)
Hand-chosen in Section III-D3c to encode operator priorities; the SLO fulfillment ratios in Table I are direct consequences of these weights, so they are free parameters that shape the reported results.
SLO thresholds (CPU, freshness, sample, cost) = SLOCPU <= 80%, SLOf at least half max frequency, SLOsample >= 50%, SLOc relative to max node capacity
Set by the authors for the simulation in Section IV-E; different thresholds would change the measured fulfillment ratios.
Number of discrete levels for actions = 4 per parameter
The discretization in Section III-D3b and IV-E determines the state-action space size (2 x 4 x 4 x 4 states, 64 actions) and is a design choice not derived from requirements.
Overload transition probability = Not stated, described as 'high probability'
The stochastic model in Section IV-E is not fully specified; the simulation results depend on this unstated parameter.

assumptions (5)

domain assumption A hierarchical computing continuum with head and edge nodes is a representative model for IoT analytics.
Used in the testbed setup (Section IV-B); the generality of the results across other continuum topologies is assumed.
domain assumption Elasticity can be decomposed into quality, resource, and cost dimensions.
Adopted from Dustdar et al. [7] in Section I and used to structure the framework.
domain assumption Changing analytics requirements (coverage, sample, freshness) has predictable monotonic effects on CPU usage.
Assumed in Section III-C and used to justify orchestrator actions; partially supported by the small testbed in Section IV-C.
standard math Q-learning converges to a near-optimal policy for the discretized state-action space.
Invoked in Section III-D3 without formal proof; standard but requires sufficient exploration and stationarity, which are not analyzed.
ad hoc to paper Nodes and application instances are identical, and CPU utilization can be treated as binary.
Stated simplification in Section III-D3b that defines the state space; this is a strong assumption not validated in the evaluation.

how reviews work

0 comments

Cite this review

Pith. "Pith review of A Multidimensional Elasticity Framework for Adaptive Data Analytics Management in the Computing Continuum." pith.science (2026). https://pith.science/paper/WMJRRNE4

@misc{pith2026250111369,
  author       = {Pith},
  title        = {Pith review of: A Multidimensional Elasticity Framework for Adaptive Data Analytics Management in the Computing Continuum},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WMJRRNE4}},
  note         = {Machine review of arXiv:2501.11369}
}

read the original abstract

The increasing complexity of IoT applications and the continuous growth in data generated by connected devices have led to significant challenges in managing resources and meeting performance requirements in computing continuum architectures. Traditional cloud solutions struggle to handle the dynamic nature of these environments, where both infrastructure demands and data analytics requirements can fluctuate rapidly. As a result, there is a need for more adaptable and intelligent resource management solutions that can respond to these changes in real-time. This paper introduces a framework based on multi-dimensional elasticity, which enables the adaptive management of both infrastructure resources and data analytics requirements. The framework leverages an orchestrator capable of dynamically adjusting architecture resources such as CPU, memory, or bandwidth and modulating data analytics requirements, including coverage, sample, and freshness. The framework has been evaluated, demonstrating the impact of varying data analytics requirements on system performance and the orchestrator's effectiveness in maintaining a balanced and optimized system, ensuring efficient operation across edge and head nodes.

Figures

Figures reproduced from arXiv: 2501.11369 by the authors.

**Figure 2.** Orchestrator with RL-Based Elasticity Management in the CC. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 3.** Impact of data analytics requirements on CPU usage. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Orchestrator adapting data analytics requirements to manage CPU [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

15 extracted references · 15 canonical work pages

[1]

A survey on iot-edge-cloud continuum systems: status, challenges, use cases, and open issues,

P. Gkonis et al., “A survey on iot-edge-cloud continuum systems: status, challenges, use cases, and open issues,” Future Internet, vol. 15, no. 12, 2023

work page 2023
[2]

Joint optimization of response time and deployment cost in next-gen iot applications,

J. L. Herrera et al., “Joint optimization of response time and deployment cost in next-gen iot applications,” IEEE Internet Things J. , vol. 10, no. 5, 2022

work page 2022
[3]

Optimizing the response time in sdn-fog environments for time- strict iot applications,

——, “Optimizing the response time in sdn-fog environments for time- strict iot applications,” IEEE Internet of Things Journal , vol. 8, no. 23, 2021

work page 2021
[4]

Simulating resource management across the cloud-to-thing continuum: A survey and future directions,

M. Bendechache et al. , “Simulating resource management across the cloud-to-thing continuum: A survey and future directions,” Future Internet, vol. 12, no. 6, 2020

work page 2020
[5]

Distributed computing continuum systems– opportunities and research challenges,

V . Casamayor Pujol et al. , “Distributed computing continuum systems– opportunities and research challenges,” in Proc. ICSOC, 2022

work page 2022
[6]

Edge intelligence—research opportunities for dis- tributed computing continuum systems,

V . C. Pujol et al. , “Edge intelligence—research opportunities for dis- tributed computing continuum systems,” IEEE Internet Comput., vol. 27, no. 4, 2023

work page 2023
[7]

Principles of elastic processes,

S. Dustdar et al. , “Principles of elastic processes,” IEEE Internet Comput., vol. 15, no. 5, 2011

work page 2011
[8]

Elastic data analytics for the cloud-to-things continuum,

S. Laso et al., “Elastic data analytics for the cloud-to-things continuum,” IEEE Internet Comput. , vol. 26, no. 6, 2022

work page 2022

Show all 15 references

[9]

Decent: A decentralized configurator for controlling elasticity in dynamic edge networks,

I. Murturi and S. Dustdar, “Decent: A decentralized configurator for controlling elasticity in dynamic edge networks,” ACM Trans. Internet Techn., vol. 22, no. 3, 2022

2022
[10]

Orchestration in the cloud-to-things compute contin- uum: taxonomy, survey and future directions,

A. Ullah et al. , “Orchestration in the cloud-to-things compute contin- uum: taxonomy, survey and future directions,”J. Cloud Comput., vol. 12, no. 1, 2023

2023
[11]

Cloud-edge orchestration for the internet of things: Architecture and ai-powered data processing,

Y . Wu, “Cloud-edge orchestration for the internet of things: Architecture and ai-powered data processing,” IEEE Internet Things J. , vol. 8, no. 16, 2020

2020
[12]

Towards service orchestration for the cloud-to-thing continuum,

I. ˇCili´c et al. , “Towards service orchestration for the cloud-to-thing continuum,” in Proc. SpliTech, 2021

2021
[13]

Pilot-edge: Distributed resource management along the edge-to-cloud continuum,

A. Luckow et al. , “Pilot-edge: Distributed resource management along the edge-to-cloud continuum,” in Proc. IEEE IPDPS Workshops , 2021

2021
[14]

Managing the cloud continuum: Lessons learnt from a real fog-to-cloud deployment,

X. Masip-Bruin et al. , “Managing the cloud continuum: Lessons learnt from a real fog-to-cloud deployment,” Sensors, vol. 21, no. 9, 2021

2021
[15]

Oppnets and rural areas: an opportunistic solution for remote communications,

M. Jes ´us-Azabal et al. , “Oppnets and rural areas: an opportunistic solution for remote communications,” Wirel. Commun. Mob. Comput. , vol. 2021, no. 1, 2021

2021

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.

[1] [1]

A survey on iot-edge-cloud continuum systems: status, challenges, use cases, and open issues,

P. Gkonis et al., “A survey on iot-edge-cloud continuum systems: status, challenges, use cases, and open issues,” Future Internet, vol. 15, no. 12, 2023

work page 2023

[2] [2]

Joint optimization of response time and deployment cost in next-gen iot applications,

J. L. Herrera et al., “Joint optimization of response time and deployment cost in next-gen iot applications,” IEEE Internet Things J. , vol. 10, no. 5, 2022

work page 2022

[3] [3]

Optimizing the response time in sdn-fog environments for time- strict iot applications,

——, “Optimizing the response time in sdn-fog environments for time- strict iot applications,” IEEE Internet of Things Journal , vol. 8, no. 23, 2021

work page 2021

[4] [4]

Simulating resource management across the cloud-to-thing continuum: A survey and future directions,

M. Bendechache et al. , “Simulating resource management across the cloud-to-thing continuum: A survey and future directions,” Future Internet, vol. 12, no. 6, 2020

work page 2020

[5] [5]

Distributed computing continuum systems– opportunities and research challenges,

V . Casamayor Pujol et al. , “Distributed computing continuum systems– opportunities and research challenges,” in Proc. ICSOC, 2022

work page 2022

[6] [6]

Edge intelligence—research opportunities for dis- tributed computing continuum systems,

V . C. Pujol et al. , “Edge intelligence—research opportunities for dis- tributed computing continuum systems,” IEEE Internet Comput., vol. 27, no. 4, 2023

work page 2023

[7] [7]

Principles of elastic processes,

S. Dustdar et al. , “Principles of elastic processes,” IEEE Internet Comput., vol. 15, no. 5, 2011

work page 2011

[8] [8]

Elastic data analytics for the cloud-to-things continuum,

S. Laso et al., “Elastic data analytics for the cloud-to-things continuum,” IEEE Internet Comput. , vol. 26, no. 6, 2022

work page 2022