pith. sign in

arxiv: 1907.05505 · v1 · pith:FELQ53XFnew · submitted 2019-07-11 · 💻 cs.LG · cs.AI· stat.ML

Artificial Intelligence as a Services (AI-aaS) on Software-Defined Infrastructure

Saeedeh Parsaeefard , Iman Tabrizian , Alberto Leon-Garcia This is my paper

Pith reviewed 2026-05-24 22:53 UTC · model grok-4.3

classification 💻 cs.LG cs.AIstat.ML
keywords AI as a servicesoftware-defined infrastructureMAPE-K loopservice chainsmachine learning pipelinetraining planesmart applicationsSAVI testbed
0
0 comments X

The pith

AI applications run as services on software-defined infrastructures by structuring them as MAPE-K loops embedded in service chains with dedicated training and operational planes.

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

The paper proposes an architectural scheme for offering artificial intelligence as a service on software-defined infrastructures. Each AI-aaS application is built around a monitoring, analysis, policy, execution plus knowledge loop realized as one or more service chains, some containing machine learning pipelines. A training plane handles model development while an AI-aaS plane manages operational deployment, and an ML/MKL sandbox maintains consistency across parallel loops. The approach is illustrated with three applications deployed on the SAVI testbed: data compression via autoencoders, CPU allocation for virtual network functions, and highway segment classification.

Core claim

The central claim is that AI-aaS can be delivered on SDIs by composing each application as a MAPE-K loop in service chains that may include ML pipelines, supported by a new training plane and AI-aaS plane to separate development and operation, plus an ML/MKL sandbox to ensure coherency and consistency when multiple loops run in parallel.

What carries the argument

The MAPE-K loop (MKL) embedded as service chains in SDI, together with a training plane and AI-aaS plane, to structure AI applications and separate their development and operational phases.

If this is right

  • Smart applications in transportation, manufacturing, energy, water, air quality, and emissions can be addressed through AI-aaS on existing SDIs.
  • Model-development and operational phases of AI applications are handled separately by the training plane and AI-aaS plane.
  • Coherency and consistency across multiple parallel MKL loops are maintained by the ML/MKL sandbox.
  • Feasibility is demonstrated by experimental results for autoencoder-based data compression, traffic monitoring for VNF CPU allocation, and highway segment classification.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The architecture implies that service chaining in SDIs can integrate ML pipelines for real-time automation without custom per-application infrastructure.
  • If the sandbox scales, it could allow dynamic addition or removal of AI services in shared infrastructures while preserving loop independence.
  • The separation of planes suggests a testable path for updating ML models in production without disrupting ongoing operational loops.

Load-bearing premise

The ML/MKL sandbox can ensure coherency and consistency across multiple parallel MKL loops when embedded as service chains in an SDI without introducing prohibitive overhead or conflicts.

What would settle it

Running multiple AI-aaS applications simultaneously on the SAVI testbed and measuring sandbox-induced overhead plus any detected inconsistencies or conflicts; substantial overhead or inconsistencies would show the claim does not hold.

Figures

Figures reproduced from arXiv: 1907.05505 by Alberto Leon-Garcia, Iman Tabrizian, Saeedeh Parsaeefard.

Figure 1
Figure 1. Figure 1: MAPE-K loop (MKL) for AI assisted management and learning in systems (AI-aaS) [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Spider diagrams for AI-aaS use cases based on required [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Multi-sandbox SDI architecture including management elements to control the interference between MKLs [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: The MKL management, orchestration and training (MKL-MOT) architectural framework. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Hierarchical and recursive structure of MKL-MOT. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Three use cases of AI-aaS on SAVI Testbed [22] and their MKL-chains based on Kubeflow [PITH_FULL_IMAGE:figures/full_fig_p006_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: General Architecture of Autoencoder For each region, there is a Prometheus server, responsible for pulling metrics from the VMs and a Ryu SDN controller to setup the flow rules. There is an HAProxy load balancer (VM 1) installed in the ”Core”, which passes the requests to the web servers, i.e., VM 6 in each region. It is installed in Toronto, Waterloo and Calgary regions to emulate realistic network delays… view at source ↗
Figure 9
Figure 9. Figure 9: Traffic Pattern of HAProxy load balancer for 30 minutes [PITH_FULL_IMAGE:figures/full_fig_p007_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Error Distribution of CPU Usage Compression [PITH_FULL_IMAGE:figures/full_fig_p007_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Traffic vs CPU Snort firewall installed in VM 4. After filtering malicious traffic, it is steered through VM 6 in each region (its original destination). SVOP (Simple VNF Orchestration Platform) [24] takes care of the deployment of Snort and installation of flow rules. To allocate a CPU to the Snort efficiently, we should predict the required CPU based on an amount of traffic passed through Snort. Here, w… view at source ↗
read the original abstract

This paper investigates a paradigm for offering artificial intelligence as a service (AI-aaS) on software-defined infrastructures (SDIs). The increasing complexity of networking and computing infrastructures is already driving the introduction of automation in networking and cloud computing management systems. Here we consider how these automation mechanisms can be leveraged to offer AI-aaS. Use cases for AI-aaS are easily found in addressing smart applications in sectors such as transportation, manufacturing, energy, water, air quality, and emissions. We propose an architectural scheme based on SDIs where each AI-aaS application is comprised of a monitoring, analysis, policy, execution plus knowledge (MAPE-K) loop (MKL). Each application is composed as one or more specific service chains embedded in SDI, some of which will include a Machine Learning (ML) pipeline. Our model includes a new training plane and an AI-aaS plane to deal with the model-development and operational phases of AI applications. We also consider the role of an ML/MKL sandbox in ensuring coherency and consistency in the operation of multiple parallel MKL loops. We present experimental measurement results for three AI-aaS applications deployed on the SAVI testbed: 1. Compressing monitored data in SDI using autoencoders; 2. Traffic monitoring to allocate CPUs resources to VNFs; and 3. Highway segment classification in smart transportation.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The manuscript proposes an architecture for AI-as-a-Service (AI-aaS) on software-defined infrastructures (SDIs), in which each application is realized as one or more MAPE-K loops (MKLs) embedded as service chains; some chains incorporate ML pipelines. The model introduces a dedicated training plane and an AI-aaS plane to separate model development from operation, together with an ML/MKL sandbox intended to maintain coherency and consistency across concurrently executing MKLs. The claims are illustrated by three experimental deployments on the SAVI testbed: autoencoder compression of monitored data, traffic-driven VNF CPU allocation, and highway-segment classification.

Significance. If the sandbox mechanism can be shown to enforce coherency without prohibitive overhead, the framework would supply a concrete, reusable pattern for embedding AI services inside existing SDI automation loops. The work also supplies a clear separation of training and inference planes that could be adopted by other SDI or NFV orchestration efforts.

major comments (2)
  1. [Experiments] Experiments section: the three reported deployments are presented as isolated applications; none is shown to involve concurrent, interacting MKL loops or to exercise the ML/MKL sandbox for conflict resolution or coherency enforcement. Because the sandbox is introduced as the mechanism that makes multiple parallel MKLs safe, the absence of any measurement or scenario exercising this function leaves the central architectural claim unsupported by the presented evidence.
  2. [Architecture] Architecture description (MAPE-K and planes): the text asserts that the sandbox will ensure consistency across service chains, yet supplies neither a formal model of the consistency invariants nor any overhead or conflict-resolution measurements that would allow a reader to assess whether the mechanism is practical.
minor comments (2)
  1. [Abstract] Abstract and experimental narrative supply no quantitative results, baselines, or error metrics for the three SAVI deployments, making it impossible to judge the practical performance of the proposed service chains.
  2. [Architecture] Notation for the training plane and AI-aaS plane is introduced without a diagram or explicit interface definition showing how they interact with the underlying SDI control plane.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments on our manuscript. The feedback correctly identifies areas where additional evidence would strengthen the presentation of the sandbox mechanism. We address each major comment below and commit to revisions that directly incorporate the suggested enhancements.

read point-by-point responses

  1. Referee: [Experiments] Experiments section: the three reported deployments are presented as isolated applications; none is shown to involve concurrent, interacting MKL loops or to exercise the ML/MKL sandbox for conflict resolution or coherency enforcement. Because the sandbox is introduced as the mechanism that makes multiple parallel MKLs safe, the absence of any measurement or scenario exercising this function leaves the central architectural claim unsupported by the presented evidence.

    Authors: We agree that the three experiments are presented as isolated deployments and do not demonstrate concurrent MKL execution or sandbox-mediated conflict resolution. This limits the direct empirical support for the sandbox's role in ensuring safety across parallel loops. In the revised manuscript we will add a dedicated subsection describing a new experimental scenario on the SAVI testbed that deploys multiple interacting MKLs concurrently, together with measurements of sandbox overhead and conflict-resolution behavior. This addition will supply the missing evidence for the central architectural claim. revision: yes

  2. Referee: [Architecture] Architecture description (MAPE-K and planes): the text asserts that the sandbox will ensure consistency across service chains, yet supplies neither a formal model of the consistency invariants nor any overhead or conflict-resolution measurements that would allow a reader to assess whether the mechanism is practical.

    Authors: The current architecture section presents the sandbox at a conceptual level. We acknowledge that a formal model of the consistency invariants and quantitative overhead data would enable readers to evaluate practicality more rigorously. The revised version will include an explicit formal specification of the invariants maintained by the sandbox (expressed as predicates over shared knowledge and service-chain state) and will report overhead and conflict-resolution measurements obtained from the additional concurrent-MKL experiment described above. revision: yes

Circularity Check

0 steps flagged

No circularity: architectural proposal with direct experimental support

full rationale

The paper advances an architectural scheme for AI-aaS on SDIs built around MAPE-K loops and service chains, plus a training/AI-aaS plane and ML/MKL sandbox concept. No equations, parameters, or formal derivations appear in the manuscript. The three reported experiments (autoencoder compression, VNF CPU allocation, highway classification) are presented as independent deployments on the SAVI testbed rather than outputs of any fitted model or self-referential definition. Central claims remain proposals and empirical observations; the sandbox coherency requirement is stated as a design goal, not derived from prior self-citations or inputs by construction. The contribution is therefore self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 3 invented entities

The central claim rests on domain assumptions about SDI flexibility and the effectiveness of the proposed planes and sandbox; no free parameters or invented entities with independent evidence are introduced beyond the architectural components themselves.

axioms (1)
  • domain assumption Software-defined infrastructures can embed MAPE-K loops and ML pipelines as service chains without prohibitive performance overhead.
    Implicit in the proposal to compose applications as service chains embedded in SDI.
invented entities (3)
  • Training plane no independent evidence
    purpose: Handle the model-development phase of AI applications.
    New architectural component introduced to separate development from operations.
  • AI-aaS plane no independent evidence
    purpose: Handle the operational phases of AI applications.
    New architectural component introduced to separate development from operations.
  • ML/MKL sandbox no independent evidence
    purpose: Ensure coherency and consistency among multiple parallel MKL loops.
    New component introduced to manage interactions between loops.

pith-pipeline@v0.9.0 · 5791 in / 1427 out tokens · 44500 ms · 2026-05-24T22:53:41.685259+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

24 extracted references · 24 canonical work pages

  1. [1]

    Feedback control as MAPE-K loop in autonomic computing

    E. Rutten and et al., “Feedback control as MAPE-K loop in autonomic computing.” Springer International Publishing, 2017, pp. 349–373

    work page 2017

  2. [2]

    Software-defined infrastructure and the future central office,

    J. Kang, H. Bannazadeh, H. Rahimi, T. Lin, M. Faraji, and A. Leon- Garcia, “Software-defined infrastructure and the future central office,” in 2013 IEEE International Conference on Communications Workshops (ICC), June 2013, pp. 225–229

    work page 2013

  3. [3]

    Unified architecture for machine learning in 5G and future networks,

    Focus group on Machine Learning for Future Networks including 5G (FG-ML5G), “Unified architecture for machine learning in 5G and future networks,” FG-ML5G-ARC5G, 01 2019

    work page 2019

  4. [4]

    A comprehensive survey on machine learning for networking: evolution, applications and research opportunities,

    R. Boutaba and et al., “A comprehensive survey on machine learning for networking: evolution, applications and research opportunities,” Journal of Internet Services and Applications , vol. 9, no. 1, p. 16, June 2018

    work page 2018

  5. [5]

    Knowledge-defined networking,

    A. Mestres and et al., “Knowledge-defined networking,” ACM SIG- COMM Computer Communication Review , vol. 47, no. 3, pp. 1– 8, 2017

    work page 2017

  6. [6]

    Improved operator experience through experiential net- worked intelligence (ENI):introduction - benefits - enablers - challenges - call for action,

    ETSI WP22, “Improved operator experience through experiential net- worked intelligence (ENI):introduction - benefits - enablers - challenges - call for action,” ETSI White Paper, vol. 22, pp. 248–268, October 2017

    work page 2017

  7. [7]

    Study of enablers for network automation for 5G (release 16),

    3GPP Technical Specification Group Services and System Aspects, “Study of enablers for network automation for 5G (release 16),” 3GPP TR 23.791 V16.0.0 (2018-12) , June 2018

    work page 2018

  8. [8]

    Evolution to an artificial intelligence enabled network,

    ATIS, “Evolution to an artificial intelligence enabled network,” Report, September 2018

    work page 2018

  9. [9]

    Acumos an open source AI machine learning platform,

    AT &T and Linux Foundation, “Acumos an open source AI machine learning platform,” https://docs.acumos.org/en/athena/architecture/intro.html, 2018

    work page 2018

  10. [10]

    [Online]

    “ONAP,” 2019. [Online]. Available: https://onap.readthedocs.io/en/ amsterdam/guides/onap-developer/architecture/onap-architecture.html

    work page 2019

  11. [11]

    Leveraging synergy of sdwn and multi-layer resource management for 5g networks,

    M. Derakhshani, S. Parsaeefard, T. Le-Ngoc, and A. Leon-Garcia, “Leveraging synergy of sdwn and multi-layer resource management for 5g networks,” IET Networks, vol. 7, no. 5, pp. 336–345, 2018

    work page 2018

  12. [12]

    Kubeflow,

    “Kubeflow,” Apr 2019, [Online; accessed 15. May 2019]. [Online]. Available: https://www.kubeflow.org

    work page 2019

  13. [13]

    CVST Live Traffic Map,

    “CVST Live Traffic Map,” May 2019, [Online; accessed 15. May 2019]. [Online]. Available: http://portal.cvst.ca

    work page 2019

  14. [14]

    Living with artificial intelligence: A paradigm shift toward future network traffic control,

    J. Xu and K. Wu, “Living with artificial intelligence: A paradigm shift toward future network traffic control,” IEEE Network, vol. 32, no. 6, pp. 92–99, November 2018

    work page 2018

  15. [15]

    5G; system architecture for the 5G system,

    ETSI Technical Specification Report, “5G; system architecture for the 5G system,” ETSI TS 123 501 V15.2.0 (2018-06) , June 2018

    work page 2018

  16. [16]

    Software-defined networking: A comprehensive survey,

    D. Kreutz, F. M. V . Ramos, P. E. Verssimo, C. E. Rothenberg, S. Azodol- molky, and S. Uhlig, “Software-defined networking: A comprehensive survey,” Proceedings of the IEEE , vol. 103, no. 1, pp. 14–76, Januay 2015

    work page 2015

  17. [17]

    A survey of the functional splits proposed for 5G mobile crosshaul networks,

    L. M. P. Larsen and et al., “A survey of the functional splits proposed for 5G mobile crosshaul networks,” IEEE Communications Surveys Tutorials, vol. 21, no. 1, pp. 146–172, Firstquarter 2019

    work page 2019

  18. [18]

    Cognet: A network management architecture featuring cognitive capabilities,

    L. Xu and et al., “Cognet: A network management architecture featuring cognitive capabilities,” in 2016 European Conference on Networks and Communications (EuCNC), June 2016, pp. 325–329

    work page 2016

  19. [19]

    Intelligent network management for 5G systems: The SELFNET approach,

    W. Jiang and et al., “Intelligent network management for 5G systems: The SELFNET approach,” in 2017 European Conference on Networks and Communications (EuCNC) , June 2017, pp. 1–5

    work page 2017

  20. [20]

    Spatio-temporal anomaly detection in intelligent transportation systems,

    M. Hassan, A. Tizghadam, and A. Leon-Garcia, “Spatio-temporal anomaly detection in intelligent transportation systems,” inThe 8th Inter- national Workshop on Agent-based Mobility, Traffic and Transportation Models (ABMTRANS), May 2019

    work page 2019

  21. [21]

    Learning internal representations by error propagation,

    D. E. Rumelhart, G. E. Hinton, and R. J. Williams, “Learning internal representations by error propagation,” California Univ San Diego La Jolla Inst for Cognitive Science, Tech. Rep., 1985. 9

    work page 1985

  22. [22]

    SA VI testbed: Control and management of converged virtual ICT resources,

    J.-M. Kang, H. Bannazadeh, and A. Leon-Garcia, “SA VI testbed: Control and management of converged virtual ICT resources,” 2013 IFIP/IEEE International Symposium on Integrated Network Management (IM 2013) , pp. 664–667, May 2013. [Online]. Available: https://ieeexplore.ieee.org/abstract/document/6573048

    work page arXiv 2013

  23. [23]

    TFX: A tensorflow-based production-scale machine learning platform,

    A. N. Modi and et al., “TFX: A tensorflow-based production-scale machine learning platform,” in KDD 2017, 2017

    work page 2017

  24. [24]

    Tabrizian/SVOP,

    “Tabrizian/SVOP,” May 2019, [Online; accessed 17. May 2019]. [Online]. Available: https://github.com/tabrizian/SVOP

    work page 2019