Pith. sign in

REVIEW 4 major objections 5 minor 32 references

Streamlining Resilient Kubernetes Autoscaling with Multi-Agent Systems via an Automated Online Design Framework

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

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

Pith's one-line read KARMA claims that decomposing Kubernetes autoscaling into role-specialized agents trained in a digital twin outperforms three state-of-the-art HPA systems in operational resilience under adversarial scenarios.

desk verdict Useful framework and ablations, but the headline performance claim is unvalidated inside a digital twin whose fidelity is not established. read the letter →

arxiv 2505.21559 v1 pith:5ABHILC5 submitted 2025-05-26 cs.MA cs.AI

Julien Soulé , Jean-Paul Jamont , Michel Occello , Louis-Marie Traonouez , Paul Théron This is my paper · ORCID
classification cs.MAcs.AI
keywords KubernetesautoscalingHorizontalPodmulti-agentreinforcementlearningoperationalresiliencedigitaltwinadversarialDDoSroleandmissiondecompositionexplainableagents
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 tries to establish that resilient Kubernetes autoscaling under adversarial conditions is better built as a team of specialized agents than as a single optimizer. It proposes KARMA, an automated four-phase framework that builds a digital twin from cluster traces, trains agents with failure-specific roles and missions, analyzes their behavior, and transfers the learned policies to the real cluster. The reported results put KARMA ahead of the three comparison systems: a 90.9% success rate and 85.7% latency compliance across five scenarios, versus 80.6% and 73.8% for the best baseline, and the lowest pending-request ratio at 5.9%. If the framework works as described, it would make resilient autoscaling design repeatable and less dependent on manual, cluster-specific tuning.

What carries the argument

The load-bearing object is the pair of role and mission specifications applied during training inside a digital twin modeled as a zero-sum stochastic game. A role is a Role Action Guide: a rule-based restriction of an agent's allowed scaling actions, either as a hard filter or as a soft reward adjustment. A mission is a Goal Reward Guide: a reward bonus or penalty that steers an agent toward an intermediate goal such as clearing a pending-request queue or keeping a DDoS-threatened entry point available. The digital twin supplies the transition function: recorded transitions are looked up directly, and unrecorded ones are predicted by a multi-layer perceptron trained on the traces, under the assumption that the next cluster state is Markovian given the current state and the chosen actions. Training uses a multi-agent reinforcement learning algorithm with a centralized critic, and the resulting policies are executed through the Kubernetes API with caps and fallback safeguards.

What would settle it

Deploy the trained policies on a live multi-node Kubernetes cluster running the mixed scenario while recording the actual transition outcomes; if the prediction error of the learned transition model grows as the trace window lengthens, or if the deployed success rate falls more than the inverse of the reported 94.9% twin-accuracy ratio below the simulation-trained rate, the Markovian transfer assumption is contradicted.

Watch

Extended reading notes

Core claim

The central discovery on the paper's own terms is that a multi-agent decomposition of operational resilience, with one specialized agent per failure mode constrained by roles and guided by missions, yields autoscaling policies that sustain service quality under bottlenecks, DDoS, pod failures, resource contention, and their combination. In the mixed scenario, the KARMA multi-agent system with hard organizational specifications reaches a 90.9% success rate, 85.7% latency compliance, and 5.9% pending requests, beating single-agent and unconstrained multi-agent variants and the three literature baselines. The same organizational structure gives the fastest DDoS recovery at 33.0 seconds and the highest service availability at 90.7%, while reducing training convergence time by about 47% relative to training without roles and missions. The paper takes these results as evidence that decomposing a resilience goal into sub-goals is not just a design convenience but a performance advantage.

Load-bearing premise

The load-bearing premise is that the next state of the Kubernetes cluster is determined by the current state and the agents' actions alone, so a neural network trained on recorded transitions can predict unobserved states; if real cluster behavior carries memory effects such as cascading failures or queue buildup, the digital twin and the policies trained in it may not transfer to the live cluster.

Editorial extensions

If this is right

  • If the framework is right, resilient autoscaling can be generated automatically for a given cluster, with roles and missions replacing hand-tuned threshold rules in the HPA controller.
  • Organizational constraints become a training accelerator: hard roles and missions converge in roughly half the episodes and a quarter of the training time of the unconstrained multi-agent variant.
  • The digital twin with learned transitions should make policy training safe: agents explore failure responses in simulation, and the reported 94.9% transition-model accuracy is the stated margin by which simulation behavior matches the real cluster.
  • The closed loop of trace collection, retraining, and redeployment gives the system a mechanism to track workload drift, assuming the transfer assumption holds across cluster changes.
  • Explainability is built in: trajectory clustering and inter-agent graph inference give operators a view of which agent is acting and who coordinates whom during an attack.

Reading between the lines

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

  • A natural extension the paper leaves implicit is applying the same role/mission decomposition to other autoscaling levers, such as vertical pod scaling or node-level cluster autoscaling, where the sub-goal structure could be reused with a new action space.
  • The single-worker-node evaluation marks the boundary of the evidence; on multi-node clusters, network partitions and cross-node cascading failures introduce dependencies that the Markovian transition model does not represent, making live transfer the decisive test.
  • The alignment score between learned behavior and predefined roles could be turned into an operational safety monitor: if trajectory clustering alignment falls below its training-time level, the system could fall back to standard HPA until policies are retrained.
  • A sharper test of generality would be to run the same four-phase pipeline without hand-tuned role definitions, letting the clustering analysis propose roles automatically and then measuring whether the resulting policies still beat the baselines.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper presents KARMA, a four-phase framework (modeling, training, analysis, transfer) for automatically designing a multi-agent HPA system for Kubernetes. A digital twin is built from cluster traces via a stochastic game with an MLP transition approximator; agents are trained with MAPPO under predefined roles (RAGs) and missions (GRGs); learned behaviors are analyzed via trajectory clustering; and policies are then deployed to the real cluster via the Kubernetes API. The authors claim that the resulting HPA MAS outperforms AWARE, Gym-HPA, and Rlad-core on operational resilience in adversarial scenarios. The reported evidence is, however, entirely from simulation, and the twin's fidelity is measured by a self-referential ratio.

Significance. If the strong experimental claims were supported by real-cluster validation, the framework would be a useful contribution: it targets an important problem (resilient autoscaling under adversarial conditions), automates MAS design, and provides an explainability pipeline. The closed-loop trace-update mechanism is also timely. The paper states in Section IV-B that KARMA's source code is publicly available, which is good reproducibility practice. Nevertheless, the central claims currently rest on a single-node simulation with no transfer results and on evaluation metrics that overlap with the training reward; the significance of the contribution cannot be assessed until these issues are addressed.

major comments (4)
  1. [Section III-B / IV-D] The central claim in the abstract (that generated HPA MASs outperform three state-of-the-art systems) is supported only by results inside the digital twin; the Digital Twin Accuracy metric in Section IV-D is defined as the ratio of real-cluster performance to simulation performance, yet no real-cluster performance numbers are reported anywhere in Section V. The Markovian transition assumption in Section III-B explicitly excludes state history, which may miss queue buildup and cascading failures; the conclusion itself concedes a Simulation-to-Reality Gap. To support the central claim, the authors must provide live-cluster transfer results (or a clear feasibility experiment) with per-scenario fidelity errors, not a single scalar.
  2. [Section III-B / V-A] The operational resilience metric or(s) used as the reward in the digital twin is the same weighted combination of success rate, pod failure rate, latency ratio, entry point availability, and traffic capacity ratio used to evaluate Gap 1 in Table II. Consequently, KARMA agents are directly optimizing the evaluation metric, whereas baselines like KHPA and Gym-HPA are not. The apparent margin (90.9% vs 80.6%) may partly reflect this reward alignment rather than a genuine improvement in operational resilience. The authors should either evaluate with an independent set of QoS metrics or train the baselines with the same reward function to enable a fair comparison.
  3. [Section III-D / V-F] The explainability evaluation in Table VII measures the alignment of learned agent behaviors with roles that were pre-imposed as hard constraints during training (Section III-C, ch=1). For hard constraints, the permitted action set is enforced by construction, so an alignment score of 96.2% is expected and does not demonstrate emergent roles. The clustering purity score is also evaluated against the same pre-defined roles. To make the claim credible, the authors should measure alignment against independently defined ground-truth behaviors (e.g., an expert-labeled benchmark), or compare with unconstrained training where roles are not pre-specified.
  4. [Section IV-D / Table II / Table IV] The statistical reporting is insufficient to support 'outperform'. Table II reports only means over 10 runs with a single standard deviation footnote; no per-cell confidence intervals, no significance tests, and no per-scenario breakdown are provided. Table IV reports a single 'accuracy' value without variance or scenario decomposition. Moreover, the protocol says baselines were run 'using source code when available,' which suggests that not all baselines were evaluated under identical conditions. The authors should provide per-scenario results with standard errors, significance tests, and a clear statement of exactly how each baseline was run.
minor comments (5)
  1. [Index Terms] The Index Terms section contains the apparent template remnant 'component, formatting, style, styling, insert'.
  2. [Figure 3] Figure 3 shows '?' placeholders in the deployment specifications; these should be replaced with the actual parameter values used.
  3. [Section III-B] The loss expression L = 1/N sum |T(...) - s'|^2 writes the loss in terms of the true transition T; since T is unknown, it should be written in terms of the recorded transitions T_t.
  4. [Table I] Table I is captioned 'A KARMA overview regarding selected HPA Systems' but does not include a KARMA column; either add the KARMA column or adjust the caption.
  5. [Section V-F] The text states that KARMA 'significantly outperforms Multi-Agent w/o Org. Spec. (85.3%)', but Table VII reports 'empty' for alignment and 62.7% for clustering purity for that baseline; the text appears to misquote the table.

Circularity Check

1 steps flagged · score 4.0 of 10

The main outperformance claim is not circular, but the role-emergence/explainability result is partly by construction because roles are enforced as hard constraints; the digital-twin fidelity metric is self-referential rather than a predictive validation.

  1. self definitional [Section III-C (Agent Roles and Missions) and Section V-F (Gap 6: Explainability, Table VII)]
    "The figure highlights the emergence of four distinct clusters, each corresponding to a specific organizational role, demonstrating the ability of the agents’ behaviors to align with the predefined roles."

    Roles are not discovered post hoc: Section III-C defines a Role Action Guide with hard constraints, and the same section states that 'A hard constraint (ch = 1) strictly limits the agent’s available actions to authorized ones.' With ch=1, each agent is restricted to a role-specific action set before training. Trajectory clustering by action sequences must therefore separate agents by role, and the reported 96.2% alignment score (Table VII) measures compliance with a constraint that was imposed a priori, not emergent role specialization. The claim that clustering 'highlights the emergence' of role-aligned clusters is thus self-definitional: the output metric (alignment with predefined roles) is built into the input definition of the roles.

full rationale

The central performance claim—that KARMA outperforms AWARE, Gym-HPA, and Rlad-core—is not circular: all systems are evaluated on the same externally defined metrics (success rate, latency compliance, pending requests) and the baselines are independent published systems. The fact that KARMA's reward function is a weighted sum of QoS components that overlap with evaluation metrics is normal RL objective alignment, not a fitted prediction masquerading as a result. The self-citation to AOMEA [10] is a methodology inspiration rather than a load-bearing proof, and the organizational model MOISE+ is independently cited [27]. The one genuine circularity is the explainability/role-emergence evaluation: hard constraints make role alignment true by construction, so the 'emergence' claim in Section V-F adds no independent evidence. The digital-twin accuracy metric (ratio of real-cluster performance to simulation performance) is self-referential and the admission of a 'Simulation-to-Reality Gap' in the conclusion is a correctness/transfer limitation, not itself a circular step. Overall, the central claim retains independent content, but the role-emergence result is partially forced by design, justifying a score of 4.

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

The central claim inherits several hand-set quantities and domain assumptions: reward weights and thresholds define what the agents optimize, the Markovian trace-based digital twin underpins training, and the roles/missions are expert-authored. These are not derived from first principles; they are tuned or assumed, which bounds the generality of the observed improvements.

free parameters (7)
  • Reward weights (w1..w5) = 0.2, 0.2, 0.2, 0.2, 0.2
    Section III-B and the implementation footnote state the weights are 'empirically tuned' to favor balanced functioning; they define the optimization objective and the evaluation metric.
  • Bottleneck queue threshold Qthreshold = 30
    Implementation footnote; used in the Bottleneck Manager detection rule; no sensitivity analysis is reported.
  • Resource contention threshold Uthreshold = 90%
    Implementation footnote; triggers Resource Manager scaling actions; no sensitivity analysis is reported.
  • Replica change bound alpha = 3
    The defender action space is replica_change in [-alpha, +alpha]; default alpha=3 is given in the implementation footnote.
  • Attacker factors sigma and kappa = sigma=10, kappa=1
    Default values from the implementation footnote control attack intensity and data alteration; they are hand-chosen.
  • Convergence thresholds mu and lambda = not specified
    Section III-C defines convergence as reward std below mu and cumulative reward above lambda, but the actual values are not given.
  • Failure and rate thresholds (Fthreshold, Rthreshold, DeltaTthreshold) = not specified
    Section IV-C introduces these thresholds for pod failure and DDoS detection rules without giving numerical values; they shape agent behavior.
assumptions (4)
  • domain assumption The next state of the Kubernetes cluster depends only on the current state and the chosen joint actions.
    Invoked in Section III-B Transition Modeling to justify the MLP transition approximator. If the cluster has history-dependent dynamics, the digital twin and transferred policies degrade.
  • domain assumption A representative set of collected traces is sufficient to build a near-realistic digital twin.
    Section III-A states traces are collected over a time window and Section III-B builds a partial transition function from them; there is no coverage guarantee for rare failure states.
  • domain assumption Operational resilience is adequately captured by a fixed linear weighted sum of five QoS metrics.
    Section III-B defines or(s) with empirically tuned equal weights; the same formula is used as the evaluation criterion, so the objective is not externally validated.
  • ad hoc to paper Roles, missions and reward structures can be pre-specified by domain experts.
    Section IV-C hard-codes four role/mission definitions; the conclusion admits dependence on domain expertise limits generalizability.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Streamlining Resilient Kubernetes Autoscaling with Multi-Agent Systems via an Automated Online Design Framework." pith.science (2026). https://pith.science/paper/5ABHILC5

@misc{pith2026250521559,
  author       = {Pith},
  title        = {Pith review of: Streamlining Resilient Kubernetes Autoscaling with Multi-Agent Systems via an Automated Online Design Framework},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5ABHILC5}},
  note         = {Machine review of arXiv:2505.21559}
}
read the original abstract

In cloud-native systems, Kubernetes clusters with interdependent services often face challenges to their operational resilience due to poor workload management issues such as resource blocking, bottlenecks, or continuous pod crashes. These vulnerabilities are further amplified in adversarial scenarios, such as Distributed Denial-of-Service attacks (DDoS). Conventional Horizontal Pod Autoscaling (HPA) approaches struggle to address such dynamic conditions, while reinforcement learning-based methods, though more adaptable, typically optimize single goals like latency or resource usage, neglecting broader failure scenarios. We propose decomposing the overarching goal of maintaining operational resilience into failure-specific sub-goals delegated to collaborative agents, collectively forming an HPA Multi-Agent System (MAS). We introduce an automated, four-phase online framework for HPA MAS design: 1) modeling a digital twin built from cluster traces; 2) training agents in simulation using roles and missions tailored to failure contexts; 3) analyzing agent behaviors for explainability; and 4) transferring learned policies to the real cluster. Experimental results demonstrate that the generated HPA MASs outperform three state-of-the-art HPA systems in sustaining operational resilience under various adversarial conditions in a proposed complex cluster.

Figures

Figures reproduced from arXiv: 2505.21559 by the authors.

Figure 1
Figure 1. Overview of the KARMA framework in use with a [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Example of inter-agent graph inferred from tra [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. A graph representation of a "Chained Services" [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Learning curves across baselines for the mixed [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Dendrogram obtained after hierarchical clustering [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

32 extracted references · 32 canonical work pages

  1. [1]

    Cloud container technologies: A state-of-the-art review,

    C. Pahl, A. Brogi, J. Soldani, and P. Jamshidi, “Cloud container technologies: A state-of-the-art review,” IEEE Transactions on Cloud Computing, vol. 7, no. 3, pp. 677–692, 2019

    work page 2019

  2. [2]

    Adaptive ai-based auto- scaling for kubernetes,

    L. Toka, G. Dobreff, B. Fodor, and B. Sonkoly, “Adaptive ai-based auto- scaling for kubernetes,” in 2020 20th IEEE/ACM Int. Symposium on Cluster, Cloud and Internet Computing (CCGrid) , 2020, pp. 599–608

    work page 2020

  3. [3]

    Borg, omega, and kubernetes,

    B. Burns, B. Grant, D. Oppenheimer, E. Brewer, and J. Wilkes, “Borg, omega, and kubernetes,” Communications of the ACM , vol. 59, no. 5, pp. 50–57, 2016

    work page 2016

  4. [4]

    Kubernetes auto-scaling: Yoyo attack vulnerability and mitigation,

    R. Ben David and A. Barr, “Kubernetes auto-scaling: Yoyo attack vulnerability and mitigation,” in Proc. of the 11th Int. Conf. on Cloud Computing and Services Science (CLOSER) . SCITEPRESS - Science and Technology Publications, 2021

    work page 2021

  5. [5]

    Reinforcement learning-based application autoscaling in the cloud: A survey,

    Yisel Garí et al., “Reinforcement learning-based application autoscaling in the cloud: A survey,” Engineering Applications of Artificial Intelli- gence, vol. 102, p. 104288, 2021

    work page 2021

  6. [6]

    Scaling up multi- agent reinforcement learning: An extensive survey on scalability issues,

    D. Liu, F. Ren, J. Yan, G. Su, W. Gu, and S. Kato, “Scaling up multi- agent reinforcement learning: An extensive survey on scalability issues,” IEEE Access, vol. 12, pp. 94 610–94 631, 2024

    work page 2024

  7. [7]

    Shoham and K

    Y . Shoham and K. Leyton-Brown, Multiagent Systems: Algorithmic, Game-Theoretic, and Logical Foundations . Cambridge University Press, 2009

    work page 2009

  8. [8]

    Applications of intelligent agents,

    N. R. Jennings and M. Wooldridge, “Applications of intelligent agents,” AI Magazine, vol. 19, no. 3, pp. 14–28, 1998

    work page 1998

Show all 32 references
  1. [9]

    Kott and M

    A. Kott and M. Arnold, Cyber Defense with Intelligent Agents. Springer, 2018

    2018

  2. [10]

    A marl-based approach for easing mas organization engineering,

    J. Soulé, J.-P. Jamont, M. Occello, P. Théron, and L.-M. Traonouez, “A marl-based approach for easing mas organization engineering,” in Artificial Intelligence Applications and Innovations: 20th IFIP WG Int. Conf., AIAI, Corfu, Greece, June 27-30, 2024, Proc. 20. Springer, 2024

    2024

  3. [11]

    AW ARE: Automate workload autoscaling with reinforcement learning in production cloud systems,

    H. Qiu, W. Mao, C. Wang, H. Franke, A. Youssef, Z. T. Kalbarczyk, T. Ba¸ sar, and R. K. Iyer, “AW ARE: Automate workload autoscaling with reinforcement learning in production cloud systems,” in 2023 USENIX Annual Technical Conf. (USENIX ATC 23) , 2023, pp. 387–402

    2023

  4. [12]

    gym-hpa: Efficient auto-scaling via reinforcement learning for complex microservice-based applications in kubernetes,

    J. Santos, T. Wauters, B. V olckaert, and F. D. Turck, “gym-hpa: Efficient auto-scaling via reinforcement learning for complex microservice-based applications in kubernetes,” in NOMS 2023-2023 IEEE/IFIP Network Operations and Management Symposium , 2023, pp. 1–9

    2023

  5. [13]

    Horizontal and vertical scaling of container-based applications using reinforcement learning,

    F. Rossi, M. Nardelli, and V . Cardellini, “Horizontal and vertical scaling of container-based applications using reinforcement learning,” in IEEE 12th Int. Conf. on Cloud Computing (CLOUD) , 2019, pp. 329–338

    2019

  6. [14]

    Development of qos-aware agents with reinforcement learning for autoscaling of microservices on the cloud,

    A. A. Khaleq and I. Ra, “Development of qos-aware agents with reinforcement learning for autoscaling of microservices on the cloud,” in Int. Conf. on Autonomic Computing and Self-Organizing Systems Companion (ACSOS), 2021, pp. 13–19

    2021

  7. [15]

    Ahpa: Adaptive horizontal pod autoscaling systems on alibaba cloud container service for kubernetes,

    Zhou Zhiqiang et al., “Ahpa: Adaptive horizontal pod autoscaling systems on alibaba cloud container service for kubernetes,” Proc. of the AAAI Conf. on Artificial Intelligence, vol. 37, no. 13, pp. 15 621–15 629, Jul. 2024

    2024

  8. [16]

    Kosmos: Vertical and horizontal resource autoscaling for kubernetes,

    L. Baresi, D. Y . X. Hu, G. Quattrocchi, and L. Terracciano, “Kosmos: Vertical and horizontal resource autoscaling for kubernetes,” in Service- Oriented Computing, H. Hacid, O. Kao, M. Mecella, N. Moha, and H.-y. Paik, Eds. Cham: Springer Int. Publishing, 2021, pp. 821–829

    2021

  9. [17]

    Copa: A combined autoscaling method for kubernetes,

    Z. Ding and Q. Huang, “Copa: A combined autoscaling method for kubernetes,” in 2021 IEEE Int. Conf. on Web Services (ICWS) , 2021, pp. 416–425

    2021

  10. [18]

    Kubernetes scheduling: Taxonomy, ongoing issues and challenges,

    C. Carrión, “Kubernetes scheduling: Taxonomy, ongoing issues and challenges,” ACM Comput. Surv., vol. 55, no. 7, 2022

    2022

  11. [19]

    A survey of autoscaling in kubernetes,

    M.-N. Tran, D.-D. Vu, and Y . Kim, “A survey of autoscaling in kubernetes,” in 2022 Thirteenth Int. Conf. on Ubiquitous and Future Networks (ICUFN), 2022, pp. 263–265

    2022

  12. [20]

    Prometheus - monitoring system and time series database,

    “Prometheus - monitoring system and time series database,” 2012, accessed: 2024-11-25. [Online]. Available: https://prometheus.io

    2012

  13. [21]

    Stochastic games,

    L. S. Shapley, “Stochastic games,” Proc. of the National Academy of Sciences, vol. 39, no. 10, pp. 1095–1100, 1953

    1953

  14. [22]

    The action spaces in openai gym,

    OpenAI Gym, “The action spaces in openai gym,” https://github.com/ openai/gym/tree/master/gym/spaces, 2022, accessed on 26 July 2022

    2022

  15. [23]

    Pettingzoo: Gym for multi-agent reinforcement learning,

    Terry, J et al., “Pettingzoo: Gym for multi-agent reinforcement learning,” Advances in Neural Information Processing Systems , 2021

    2021

  16. [24]

    The surprising effectiveness of ppo in cooperative multi-agent games,

    Yu, Chao et al., “The surprising effectiveness of ppo in cooperative multi-agent games,” in Advances in Neural Information Processing Systems, S. Koyejo et al., Ed., vol. 35, 2022, pp. 24 611–24 624

    2022

  17. [25]

    Optuna: A next-generation hyperparameter op- timization framework,

    Akiba Takuya et al., “Optuna: A next-generation hyperparameter op- timization framework,” in Proc. of the ACM SIGKDD Int. Conf. on Knowledge Discovery and Data Mining . ACM, 2019, pp. 2623–2631

    2019

  18. [26]

    Using dynamic time warping to find patterns in time series,

    D. J. Berndt and J. Clifford, “Using dynamic time warping to find patterns in time series,” Proc. of the 3rd Int. Conf. on Knowledge Discovery and Data Mining , pp. 359–370, 1994

    1994

  19. [27]

    Moise+: Towards a structural, functional, and deontic model for multi-agent organizations,

    J. F. Hübner, J. S. Sichman, and O. Boissier, “Moise+: Towards a structural, functional, and deontic model for multi-agent organizations,” Proc. of the 1st Int. Joint Conf. on Autonomous Agents and Multiagent Systems, pp. 501–502, 2002

    2002

  20. [28]

    Locust Team, “Locust,” https://locust.io, 2021

    2021

  21. [29]

    Autonomous intelligent cyber-defense agent reference architecture. release 2.0,

    A. Kott, P. Théron, M. Drašar, E. Dushku, B. LeBlanc, P. Losiewicz, A. Guarino, L. Mancini, A. Panico, M. Pihelgas et al. , “Autonomous intelligent cyber-defense agent reference architecture. release 2.0,” arXiv preprint arXiv:1803.10664, 2018

    2018 arXiv

  22. [30]

    Deep reinforcement learning based smart mitigation of ddos flooding in software-defined networks,

    Liu Yandong et al., “Deep reinforcement learning based smart mitigation of ddos flooding in software-defined networks,” in IEEE 23rd Int. Workshop on Computer Aided Modeling and Design of Communication Links and Networks (CAMAD) , 2018

    2018

  23. [31]

    Shahrad, Resource-efficient Management of Large-scale Public Cloud Systems

    M. Shahrad, Resource-efficient Management of Large-scale Public Cloud Systems. Princeton University, 2020

    2020

  24. [32]

    A comprehensive survey on container resource allocation approaches in cloud computing: State-of-the-art and research challenges,

    V . K. Netaji and G. Bhole, “A comprehensive survey on container resource allocation approaches in cloud computing: State-of-the-art and research challenges,” Web Intelligence, vol. 19, no. 4, pp. 295–316, 2022

    2022

Pith tools

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