Pith. sign in

REVIEW 4 major objections 5 minor 54 references

Declarative Application Management in the Fog. A bacteria-inspired decentralised approach

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 decentralised, declarative controller using only local data - MARIO2 - keeps fog application instances near mobile users within one to two management cycles.

desk verdict MARIO2 is a credible incremental extension of MARIO, but the scalability claim outstrips the evidence and the formal semantics hides a gap between parallel acceptance and sequential simulation. read the letter →

arxiv 2501.09964 v1 pith:KEZSCIXE submitted 2025-01-17 cs.DC

Antonio Brogi , Stefano Forti , Carlos Guerrero , Isaac Lera This is my paper · ORCID
classification cs.DC
keywords fogcomputingdecentralisedapplicationmanagementdeclarativeprogrammingbacteria-inspiredusermobilityCloud-IoTcontinuumPrologself-organisation
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 claims that fog application management can be fully decentralised yet still react promptly to user mobility, by letting each application instance act like a bacterium: sense only its local surroundings and choose among three operations - migrate, replicate (split), or undeploy (die) - according to declarative rules written in Prolog. The claim is that this suffices for scalability, since each agent's decision problem depends on the number of neighbours rather than the size of the infrastructure, and for flexibility, since operators declare per-application policies instead of relying on a one-size-fits-all optimiser. The authors support the claim with a formal operational semantics, an open-source prototype called MARIO2, and simulations over a lifelike 85-node Cloud-IoT topology driven by real taxi traces in Rome, measuring convergence, inhibited operations, response times, and service usage. The central experimental result is that after a user handover the system reaches a temporarily steady allocation within 1 to 2 management cycles on average, with about one management operation per user movement.

What carries the argument

The central mechanism is the 'bacterion' agent: a tuple (i, a, p) pairing an application instance with a management policy, embedded in host nodes (n, An, Kn, Pn) that provide contextual data and an acceptance policy. Each agent evaluates its policy p against only the local data Kn - its host's free hardware, request rates from neighbours, and experienced end-to-end latencies - and issues one of three requests: migrate to a neighbour, replicate on the same or a neighbouring node, or undeploy. A labelled transition system (rule r1) then enacts all accepted requests in parallel and inhibits the rest, while rule r2 lets contextual data change arbitrarily at any time. The Prolog prototype implements each policy as clauses of the form operation(OperationId, ServiceInstanceId, TargetNode) :- TriggeringCondition, using clause ordering to express priorities among operations and facts of the form inhibited(...) to give agents memory of recently refused actions.

What would settle it

Run the Rome taxi-trace scenario with a deliberately naive acceptance policy that checks only the requesting agent's needs against the node's current free hardware, ignoring other requests accepted in the same management cycle, and count how many times a node's committed hardware exceeds its capacity; any such overcommitment shows that rule (r1)'s parallel enactment requires an unstated coordination assumption, while its absence would support the model's stability as claimed.

Watch

Extended reading notes

Core claim

On its own terms, the paper establishes that a decentralised, declarative management loop - where each application instance is an autonomous agent equipped with three bacteria-inspired operations (motility as migration, binary fission as replication, apoptosis as undeployment) and only locally available data (free hardware on its own node, request rates and latencies reported by neighbouring nodes) - can manage applications in opportunistic Cloud-IoT infrastructures without any global view. Four declarative Prolog policies (workload-aware, latency-aware, both, and both with memory of inhibited actions) drive the simulated system to a steady allocation within about one management cycle after user movements, with the memory-augmented policy reducing inhibited operations by more than 80% compared with the non-memory version. The paper also shows that different classes of applications (workload-sensitive versus latency-sensitive) can be steered toward different parts of the infrastructure by choosing the appropriate policy, trading off response time against service usage as expected.

Load-bearing premise

The system's behaviour rests on the implicit assumption that a node's acceptance policy correctly resolves simultaneous requests from many agents, so that accepted migrations and replications never together exceed the node's hardware capacity; the formal semantics (rule r1) leaves this policy Pn unspecified while enacting all accepted requests in parallel.

Editorial extensions

If this is right

  • Fog operators can react to user mobility and workload shifts with only local monitoring: the system settles after each handover in about 1-2 management cycles, averaging roughly one management operation per user movement.
  • Scalability no longer requires a global view: each agent solves a decision problem bounded by the node degree (5 in the experiments) rather than the infrastructure size, so adding nodes does not increase per-agent decision cost.
  • Application-specific policies become cheap to express: different classes of applications (workload-sensitive versus latency-sensitive) can be directed toward different parts of the infrastructure purely by changing declarative rules.
  • A small memory of recently inhibited operations is enough to avoid thrashing: Policy 4 cuts inhibited operations by more than 80% compared with Policy 3 while keeping convergence time at about 2 cycles on average.
  • The approach removes the central controller as a single point of failure: the crash of one node does not prevent other instances from replicating to compensate.

Reading between the lines

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

  • A direct stress test the paper does not run: implement the node acceptance policy Pn as a naive check of current free hardware only, ignoring other requests accepted in the same batch, and measure how often a node's resources are overcommitted after a burst of simultaneous migrate/replicate requests; the formal semantics in Section 2.2 leaves Pn unspecified and would need this behaviour to be safe
  • Because convergence in the experiments is measured against a fixed management-cycle period, an extrapolation worth testing is the behaviour as handover frequency approaches cycle frequency; the observed 1-2 cycle convergence may degrade into oscillation when movements outpace the evaluation period.
  • The local-data model suggests a scaling law the paper only hints at: as long as the network graph keeps bounded degree, total management traffic and per-agent decision time should stay roughly constant as the number of nodes grows, which is directly measurable in a simulator by scaling node count while holding degree fixed.
  • The bio-inspired mapping points to further operations the paper lists as future work - spore formation and evolution - which would correspond to service adaptation and versioning; the same operational semantics could plausibly accommodate them as new request types.
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.

Referee Report

4 major / 5 minor

Summary. The paper presents MARIO2, a declarative and fully decentralised application-management framework for Cloud-IoT and Fog infrastructures. It draws an analogy between bacteria behaviour and three management operations (migrate, replicate, undeploy), gives a labelled transition system semantics for the resulting agents, implements the approach as Prolog policies, and evaluates four policies in the YAFS simulator on a Rome taxi-traces scenario with user mobility. The central claim is that MARIO2 scales and promptly reacts to mobility because each agent uses only locally available data, and the experiments are offered as validation of that claim.

Significance. If the claims hold, the paper contributes a useful combination of declarative policy specification, decentralised decision-making, and an open-source simulation prototype for Fog application management. The strengths are that the policies are explicit Prolog programs, the prototype is publicly available, the simulation uses real mobility traces, and there is no parameter fitting to target outcomes. However, the significance is currently undercut by a formal gap between the semantics and the implementation, and by an evaluation that lacks baselines, repeated runs, and statistical support for its headline claims.

major comments (4)
  1. [§2.2, rule (r1)] The acceptance predicate Pn is left unspecified, and the set of accepted requests A is defined by checking each request individually, after which the paper states that 'Accepted requests A are all enacted in parallel'. Because Pn tests a single request against the node's current contextual data, two accepted replication or migration requests can target the same node and individually pass while jointly exceeding the node's free hardware. Thus the model does not enforce resource-consistency. This is a load-bearing issue for the claimed correctness of the decentralised approach. Please specify Pn as a batch-consistency condition over A, or add an explicit assumption about arbitration among concurrent requests, and prove or argue that parallel enactment preserves capacity constraints.
  2. [§4.1] In the YAFS implementation, MARIO2 is described as a single DES process that 'periodically evaluates all operation requested by the DES agents' and decides to perform or inhibit each operation. This is a centralised arbitration point, and it is precisely the kind of mechanism that could prevent the overcommitment problem identified in §2.2. The paper should explain how acceptance decisions are made and communicated in a distributed way, or explicitly qualify the 'fully decentralised' claim to reflect that the prototype uses a central simulator-level arbiter.
  3. [§4.3 and Table 2] The experimental evaluation compares only the four MARIO2 policies against one another. There is no baseline such as a static cloud-only placement, a centralised optimisation approach, or a different decentralised algorithm. In addition, the reported values for response time, service usage, and convergence cycles come from what appears to be a single run with no confidence intervals or standard deviations. The claim that MARIO2 reacts 'viz. 1 on average' management cycles is therefore not statistically supported. Please add repeated runs and baseline comparisons, or temper the validation claim accordingly.
  4. [§4.4] The scalability section argues by inspection that the time to accept or reject requests is independent of the number of nodes and bacteria, but no simulation or measurement actually varies the infrastructure size, the number of users, or the number of applications. The empirical scalability claim is therefore not demonstrated by the paper's experiments. Either add scaling experiments, or restrict the claim to the architectural argument that local reasoning avoids global state.
minor comments (5)
  1. [Abstract] There is a typo in the first sentence: 'hterogeneous' should be 'heterogeneous'.
  2. [§3.3] In the text before Policy 2, 'P olicy' should be 'Policy'.
  3. [§4.2] The sentence 'The simulation were carried on with the YAFS simulator' should read 'were carried out', and the paragraph later repeats 'As shown in Fig. 8' twice; please reword.
  4. [§4.3, first paragraph] The sentence 'WS apps were defined with a low capacity of request response and, on the contrary, the LS were defined with a low capacity of request response' is internally contradictory; given Fig. 9 and the subsequent discussion, the LS applications should be described as having a high request capacity.
  5. [Figures 16–18] Figure 17b reports 'r = --' without explanation; the caption should state that the correlation coefficient is undefined because one series is constant.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the declared Prolog policies are hand-written inputs, the simulation outcomes are emergent observations, and the self-citations are contextual rather than load-bearing.

full rationale

No circular step can be exhibited. The formal semantics in Section 2.2 defines accepted requests via an unspecified per-node predicate Pn, and the paper states that accepted requests are enacted in parallel; this is an underspecification that may allow over-commitment under concurrent replication, but it does not make any of the paper's empirical claims true by construction. The four management policies in Section 3.3 are hand-written Prolog rules whose triggering conditions are expressed in terms of service descriptors, locally available facts (requests/4, node/2, service/4, serviceInstance/3) and, for Policy 4, the agent's own knowledge of recently inhibited operations; they are not fitted to the experimental results. The simulation outcomes in Section 4 — numbers of instances, inhibited actions, cycles-to-steady-state, Pearson correlations, and response times — emerge from executing those rules in YAFS over the Rome taxi-trace scenario, and none of these reported quantities is defined as an input to the rules. The scalability argument in Section 4.4 is an informal complexity argument based on locality and claimed parallel evaluation, not a derivation from a self-citation. Self-citations to [15] (previous MARIO work) and [16] (the YAFS simulator) are contextual or tool-related; no load-bearing claim reduces to them, and no uniqueness theorem or fitted ansatz is imported from the authors' prior work. The validation is self-referential in the weak sense that the authors evaluate their own policies on their own simulator with no external baseline, but that is a matter of evidence strength and correctness risk, not circularity: the measured '1-2 management cycles on average' are observations of the executed simulation, not quantities engineered to equal their inputs. The mismatch between the formal 'all accepted requests enacted in parallel' model and the single MARIO2 process that sequentially evaluates requests in the YAFS implementation is a fidelity concern, but it does not make any result reduce to its own assumption.

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

The central claim does not depend on any fitted statistical model. The free parameters are scenario constants hand-chosen by the authors, and they shape the simulation results. The semantics leaves the acceptance policy Pn unspecified, which is a domain assumption rather than an invented entity. No new particles, forces, dimensions, or mediators are introduced.

free parameters (4)
  • WS app request capacity and latency tolerance = MaxRequestRate=5, MaxLatencyToClient=10 ms
    Hand-chosen so workload-sensitive apps overload under Policy 1 and stay put under Policy 2, making the expected behaviors appear.
  • LS app request capacity and latency tolerance = MaxRequestRate=40, MaxLatencyToClient=1 ms
    Hand-chosen so latency-sensitive apps violate latency at the cloud and move to edge under Policy 2.
  • Fog node hardware capacities and link latencies = Cloud unbounded, mini-DC 9, edge 6, AP 1 units; latencies 3/2/3 ms
    Assumed topology, not derived from a dataset; the central simulation results depend on these values.
  • Simulation timing parameters = 52,000 simulation units; user movement every 2,000 units; 81 handovers; management evaluation period unspecified
    The reported 1-2 cycles to convergence is measured in management cycles, not wall-clock time, and the evaluation period is not stated.
assumptions (4)
  • domain assumption Node acceptance policies Pn correctly prevent resource overcommitment when all accepted requests are enacted in parallel.
    Rule (r1) accepts every request satisfying Pn and applies all accepted requests in one parallel step; Pn is left unspecified, so nothing in the semantics prevents simultaneous accepts from exceeding node capacity.
  • domain assumption Agents have accurate, fresh local monitoring data for free hardware, request rates, and latencies.
    Rule (r2) lets Kn change arbitrarily; no staleness or failure model is included, yet decisions depend on this data.
  • domain assumption The labeled transition system's parallel execution is a faithful model of distributed runtime behavior.
    The paper does not model communication delays, partial failures, or races between agents and node managers.
  • domain assumption Exhaustive search over small local instances is always feasible, so worst-case exp-time placement is mastered.
    Section 4.4 assumes exhaustive local evaluation is feasible with few tens of nodes; no complexity analysis or runtime measurements support this.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Declarative Application Management in the Fog. A bacteria-inspired decentralised approach." pith.science (2026). https://pith.science/paper/KEZSCIXE

@misc{pith2026250109964,
  author       = {Pith},
  title        = {Pith review of: Declarative Application Management in the Fog. A bacteria-inspired decentralised approach},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KEZSCIXE}},
  note         = {Machine review of arXiv:2501.09964}
}
read the original abstract

Orchestrating next gen applications over hterogeneous resources along the Cloud-IoT continuum calls for new strategies and tools to enable scalable and application-specific managements. Inspired by the self-organisation capabilities of bacteria colonies, we propose a declarative, fully decentralised application management solution, targeting pervasive opportunistic Cloud-IoT infrastructures. We present acustomisable declarative implementation of the approach and validate its scalability through simulation over motivating scenarios, also considering end-user's mobility and the possibility to enforce application-specific management policies for different classes of applications.

Figures

Figures reproduced from arXiv: 2501.09964 by the authors.

Figure 1
Figure 1. Bacteria functionalities and corresponding [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Knowledge base of a MARIO2 application management agent. As sketched in Fig. 2b, the application instance s1 is receiving 2 requests from ap￾plication clients c2 and c3, following two alternative routing paths (i.e. n41– n42 and n40– n41– n42), respectively. As illustrated in [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. Policy 1: workload-aware management. (1a) Si cannot handle the total amount of incoming requests as it exceeds the MaxRequestRate it can handle (line 6), AND (2) all the requests for Si have the same neighbour M (different from self, viz. dif(M, self)) as last hop in their routing path (line 7). Finally, a replicate operation of Si in node M triggers when the aforementioned condition (1a) holds. The chosen target no… view at source ↗
Figures from the paper (15 more)
Figure 4
Figure 4. Figure 4: Policy 2: latency-aware management [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: Policy 3: workload- and latency-aware management. [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: Policy 4: workload- and latency-aware management, with memory. [PITH_FULL_IMAGE:figures/full_fig_p013_6.png]
Figure 7
Figure 7. Figure 7: Taxi traces and Fog nodes projected on the map of Rome. [PITH_FULL_IMAGE:figures/full_fig_p014_7.png]
Figure 8
Figure 8. Figure 8: Infrastructure topology. % service(ServiceId, RequiredHW, MaxRequestRate, MaxLatencyToClient). %% workload-sensitive %% service(app1, 1, 5, 10). service(app2, 1, 5, 10). service(app3, 1, 5, 10). %% latency sensitive %% service(app4, 1, 40, 1). service(app5, 1, 40, 1). …
Figure 9
Figure 9. Figure 9: Example applications. (latency-aware) is used. On the other hand, LS applications are expected to move closer to edge nodes when Policy 2 (latency-aware) and Policy 3 and Policy 4 (workload- and latency-aware) are used, and to remain in the cloud when Policy 1 (workloa…
Figure 10
Figure 10. Figure 10: Initial experiment setup. 4.3 Results and discussion The objective of our simulations is to assess both dynamic (i.e. transient) and static (i.e. steady) application deployment conditions. On one hand, they aim at assessing how promptly the proposed declarative, fully…
Figure 11
Figure 11. Figure 11: Experiments with Policy 1 . migrated only incurring in nop operations. This brings to zero the number inhibited operations, as less resources are consumed in resource-constrained node at the edge [PITH_FULL_IMAGE:figures/full_fig_p018_11.png]
Figure 12
Figure 12. Figure 12: Experiments with Policy 2 [PITH_FULL_IMAGE:figures/full_fig_p020_12.png]
Figure 13
Figure 13. Figure 13: Experiments with Policy 3 [PITH_FULL_IMAGE:figures/full_fig_p021_13.png]
Figure 14
Figure 14. Figure 14: Experiments with Policy 4 (memory size 1) [PITH_FULL_IMAGE:figures/full_fig_p022_14.png]
Figure 15
Figure 15. Figure 15: Experiments with Policy 4 (memory size 10) [PITH_FULL_IMAGE:figures/full_fig_p024_15.png]
Figure 16
Figure 16. Figure 16: Pearson correlation coefficient for Policy 1 . 0 5 10 15 20 MARIO activations 0 10 20 30 40 50 Frequency Pearson correlation coefficient r = 0.980 Operations User Movements (a) All applications 0 5 10 15 20 MARIO activations 0 5 10 15 20 25 Frequency Pearson correlati…
Figure 17
Figure 17. Figure 17: Pearson correlation coefficient for Policy 2 . between the requests received and the total number of requests that can be served by a service. The average values of response times and service usages are shown in [PITH_FULL_IMAGE:figures/full_fig_p025_17.png]
Figure 18
Figure 18. Figure 18: Pearson coefficient for Policy 3 [PITH_FULL_IMAGE:figures/full_fig_p026_18.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

54 extracted references · 54 canonical work pages

  1. [1]

    Fog Computing: A Comprehensive Architectural Survey,

    P. Habibi, M. Farhoudi, S. Kazemian, S. Khorsandi, and A. Leon-Garcia, “Fog Computing: A Comprehensive Architectural Survey,” IEEE Access, vol. 8, pp. 69105–69133, 2020

    work page 2020

  2. [2]

    Osmosis: The osmotic computing platform for microelements in the cloud, edge, and internet of things,

    M. Villari, M. Fazio, S. Dustdar, O. Rana, D. N. Jha, and R. Ranjan, “Osmosis: The osmotic computing platform for microelements in the cloud, edge, and internet of things,” Computer, vol. 52, no. 8, pp. 14–26, 2019

    work page 2019

  3. [3]

    A survey of multi-access edge computing in 5g and beyond: Fundamentals, technology integration, and state-of-the-art,

    Q.-V. Pham, F. Fang, V. N. Ha, M. J. Piran, M. Le, L. B. Le, W.-J. Hwang, and Z. Ding, “A survey of multi-access edge computing in 5g and beyond: Fundamentals, technology integration, and state-of-the-art,” IEEE Access, vol. 8, pp. 116974–117017, 2020

    work page 2020

  4. [4]

    Multi-access edge computing: A survey,

    A. Filali, A. Abouaomar, S. Cherkaoui, A. Kobbane, and M. Guizani, “Multi-access edge computing: A survey,” IEEE Access, 2020

    work page 2020

  5. [5]

    How to Place Your Apps in the Fog: State of the Art and Open Challenges,

    A. Brogi, S. Forti, C. Guerrero, and I. Lera, “How to Place Your Apps in the Fog: State of the Art and Open Challenges,” Softw. Pract. Exp., vol. 50, no. 5, pp. 719–740, 2020

    work page 2020

  6. [6]

    Application Management in Fog Com- puting Environments: A Taxonomy, Review and Future Directions,

    R. Mahmud, K. Ramamohanarao, and R. Buyya, “Application Management in Fog Com- puting Environments: A Taxonomy, Review and Future Directions,”ACM Comput. Surv., vol. 53, no. 4, 2020

    work page 2020

  7. [7]

    Research challenges in nextgen service orchestration,

    L. M. Vaquero, F. Cuadrado, Y. Elkhatib, J. Bernal-Bernabe, S. N. Srirama, and M. F. Zhani, “Research challenges in nextgen service orchestration,” Future Gener. Comput. Syst., vol. 90, pp. 20 – 38, 2019

    work page 2019

  8. [8]

    Resource management approaches in fog computing: a comprehensive review,

    M. Ghobaei-Arani, A. Souri, and A. A. Rahmanian, “Resource management approaches in fog computing: a comprehensive review,” Journal of Grid Computing, vol. 18, no. 1, pp. 1–42, 2020

    work page 2020

Show all 54 references
  1. [9]

    Continuous reasoning for managing next-gen distributed applica- tions,

    S. Forti and A. Brogi, “Continuous reasoning for managing next-gen distributed applica- tions,” in ICLP Technical Communications 2020, vol. 325 of EPTCS, pp. 164–177, 2020

    2020

  2. [10]

    Migration-aware genetic optimization for mapreduce scheduling and replica placement in hadoop,

    C. Guerrero, I. Lera, and C. Juiz, “Migration-aware genetic optimization for mapreduce scheduling and replica placement in hadoop,” Journal of Grid Computing, vol. 16, no. 2, pp. 265–284, 2018

    2018

  3. [11]

    Op- portunistic Fog for IoT: Challenges and Opportunities,

    N. Fernando, S. W. Loke, I. Avazpour, F. Chen, A. B. Abkenar, and A. Ibrahim, “Op- portunistic Fog for IoT: Challenges and Opportunities,” IEEE Internet Things J., vol. 6, no. 5, pp. 8897–8910, 2019

    2019

  4. [12]

    Modelling and simulation of Opportunistic IoT Services with Aggregate Computing,

    R. Casadei, G. Fortino, D. Pianini, W. Russo, C. Savaglio, and M. Viroli, “Modelling and simulation of Opportunistic IoT Services with Aggregate Computing,” Future Gener. Comput. Syst., vol. 91, pp. 252 – 262, 2019

    2019

  5. [13]

    Algoritmo descentralizado para la asignaci´ on de servi- cios en arquitecturas de fog computing basado en un proceso expansivo de migraci´ on de instancias,

    I. Lera, C. Guerrero, and C. Juiz, “Algoritmo descentralizado para la asignaci´ on de servi- cios en arquitecturas de fog computing basado en un proceso expansivo de migraci´ on de instancias,” in Jornadas SARTECO, 2019

    2019

  6. [14]

    Scalable decentralized indexing and querying of multi- streams in the fog,

    P. Dazzi and M. Mordacchini, “Scalable decentralized indexing and querying of multi- streams in the fog,” Journal of Grid Computing, vol. 18, no. 3, pp. 395–418, 2020

    2020

  7. [15]

    Towards Declarative Decentralised Applica- tion Management in the Fog,

    A. Brogi, S. Forti, C. Guerrero, and I. Lera, “Towards Declarative Decentralised Applica- tion Management in the Fog,” in GAUSS, 2020. In press

    2020

  8. [16]

    YAFS: A simulator for IoT scenarios in Fog computing,

    I. Lera, C. Guerrero, and C. Juiz, “YAFS: A simulator for IoT scenarios in Fog computing,” IEEE Access, vol. 7, pp. 91745–91758, 2019

    2019

  9. [17]

    CRA WDAD dataset roma/taxi (v. 2014-07-17)

    L. Bracciale, M. Bonola, P. Loreti, G. Bianchi, R. Amici, and A. Rabuffi, “CRA WDAD dataset roma/taxi (v. 2014-07-17).” https://crawdad.org/roma/taxi/20140717/taxicabs, 2014

    2014

  10. [18]

    L. A. Urry, M. L. Cain, S. Wasserman, P. Minorsky, and R. Jane, Campbell Biology (11th edition). Pearson, 2017

    2017

  11. [19]

    Bacterial programmed cell death: making sense of a paradox,

    K. W. Bayles, “Bacterial programmed cell death: making sense of a paradox,” Nature Reviews Microbiology, vol. 12, no. 1, pp. 63–69, 2014

    2014

  12. [20]

    Measuring the Fog, Gently,

    A. Brogi, S. Forti, and M. Gaglianese, “Measuring the Fog, Gently,” in ICSOC, pp. 523– 538, 2019. Declarative Application Management in the Fog 31

    2019

  13. [21]

    Lightweight self-organising distributed monitoring of Fog infrastructures,

    S. Forti, M. Gaglianese, and A. Brogi, “Lightweight self-organising distributed monitoring of Fog infrastructures,” Future Gener. Comput. Syst., vol. 114, pp. 605–618, 2021. ( In press)

    2021

  14. [22]

    Monitoring self- adaptive applications within edge computing frameworks: A state-of-the-art review,

    S. Taherizadeh, A. C. Jones, I. Taylor, Z. Zhao, and V. Stankovski, “Monitoring self- adaptive applications within edge computing frameworks: A state-of-the-art review,” J. Syst. Softw., vol. 136, pp. 19–38, 2018

    2018

  15. [23]

    Evaluation and efficiency comparison of evolutionary al- gorithms for service placement optimization in fog architectures,

    C. Guerrero, I. Lera, and C. Juiz, “Evaluation and efficiency comparison of evolutionary al- gorithms for service placement optimization in fog architectures,” Future Gener. Comput. Syst., vol. 97, pp. 131–144, 2019

    2019

  16. [24]

    The prolog debugger and declarative programming,

    W. Drabent, “The prolog debugger and declarative programming,” in International Symposium on Logic-Based Program Synthesis and Transformation, pp. 193–208, Springer, 2019

    2019

  17. [25]

    Meet genetic algorithms in monte carlo: optimised placement of multi-service applications in the fog,

    A. Brogi, S. Forti, C. Guerrero, and I. Lera, “Meet genetic algorithms in monte carlo: optimised placement of multi-service applications in the fog,” in 2019 IEEE International Conference on Edge Computing (EDGE), pp. 13–17, IEEE, 2019

    2019

  18. [26]

    Mapping virtual machines onto physical machines in cloud computing: A survey,

    I. Pietri and R. Sakellariou, “Mapping virtual machines onto physical machines in cloud computing: A survey,” ACM Comput. Surv., vol. 49, no. 3, pp. 1–30, 2016

    2016

  19. [27]

    Cloud resource orchestration in the multi-cloud landscape: a systematic review of existing frameworks,

    O. Tomarchio, D. Calcaterra, and G. D. Modica, “Cloud resource orchestration in the multi-cloud landscape: a systematic review of existing frameworks,” J. Cloud Comput., vol. 9, p. 49, 2020

    2020

  20. [28]

    Heterogeneous resource allocation in Cloud Management,

    S. Kadioglu, M. Colena, and S. Sebbah, “Heterogeneous resource allocation in Cloud Management,” in NCA, pp. 35–38, 2016

    2016

  21. [29]

    Rhizoma: a runtime for self-deploying, self-managing overlays,

    Q. Yin, A. Sch¨ upbach, J. Cappos, A. Baumann, and T. Roscoe, “Rhizoma: a runtime for self-deploying, self-managing overlays,” in Middleware 2009, pp. 184–204, 2009

    2009

  22. [30]

    Self-optimising decentralised service placement in heterogeneous cloud federation,

    E. Carlini, M. Coppola, P. Dazzi, M. Mordacchini, and A. Passarella, “Self-optimising decentralised service placement in heterogeneous cloud federation,” in SASO, pp. 110– 119, 2016

    2016

  23. [31]

    Towards decentralised resilient community clouds,

    A. Sathiaseelan, M. Selimi, C. Molina, A. Lertsinsrubtavee, L. Navarro, F. Freitag, F. Ramos, and R. Baig, “Towards decentralised resilient community clouds,” in MECC, pp. 1–6, 2017

    2017

  24. [32]

    Towards the decentralised cloud: Survey on approaches and challenges for mobile, ad hoc, and edge computing,

    A. J. Ferrer, J. M. Marqu` es, and J. Jorba, “Towards the decentralised cloud: Survey on approaches and challenges for mobile, ad hoc, and edge computing,” ACM Comput. Surv., vol. 51, no. 6, pp. 1–36, 2019

    2019

  25. [33]

    Dynamical service deployment and replacement in resource-constrained edges,

    Z. Xiang, S. Deng, J. Taheri, and A. Y. Zomaya, “Dynamical service deployment and replacement in resource-constrained edges,” Mob. Networks Appl., vol. 25, no. 2, pp. 674– 689, 2020

    2020

  26. [34]

    The problem of task allocation in the internet of things and the consensus-based approach,

    G. Colistra, V. Pilloni, and L. Atzori, “The problem of task allocation in the internet of things and the consensus-based approach,” Comput. Networks, vol. 73, pp. 98 – 111, 2014

    2014

  27. [35]

    GRECO: A distributed genetic algorithm for reliable application placement in hybrid clouds,

    R. Mennes, B. Spinnewyn, S. Latr´ e, and J. F. Botero, “GRECO: A distributed genetic algorithm for reliable application placement in hybrid clouds,” in CloudNet, pp. 14–20, 2016

    2016

  28. [36]

    A lightweight decentralized service placement policy for performance optimization in fog computing,

    C. Guerrero, I. Lera, and C. Juiz, “A lightweight decentralized service placement policy for performance optimization in fog computing,” J. Ambient Intell. Humaniz. Comput., vol. 10, no. 6, pp. 2435–2452, 2019

    2019

  29. [37]

    Toward bio-inspired auto-scaling algorithms: An elasticity ap- proach for container orchestration platforms,

    J. Herrera and G. Molt´ o, “Toward bio-inspired auto-scaling algorithms: An elasticity ap- proach for container orchestration platforms,” IEEE Access, vol. 8, pp. 52139–52150, 2020

    2020

  30. [38]

    Geo-distributed efficient deployment of containers with kubernetes,

    F. Rossi, V. Cardellini, F. Lo Presti, and M. Nardelli, “Geo-distributed efficient deployment of containers with kubernetes,” Comput. Commun., vol. 159, pp. 161 – 174, 2020

    2020

  31. [39]

    Practical declar- ative network management,

    T. L. Hinrichs, N. S. Gude, M. Casado, J. C. Mitchell, and S. Shenker, “Practical declar- ative network management,” in WREN, pp. 1–10, 2009

    2009

  32. [40]

    Declarative application deployment and change management,

    S. Herden, A. Zwanziger, and P. Robinson, “Declarative application deployment and change management,” in CNSM, pp. 126–133, 2010

    2010

  33. [41]

    Probabilistic QoS-aware Placement of VNF chains at the Edge,

    S. Forti, F. Paganelli, and A. Brogi, “Probabilistic QoS-aware Placement of VNF chains at the Edge,” Theory and Practice of Logic Programming, 2021. In press

    2021

  34. [42]

    Secure Cloud-Edge Deployments, with Trust,

    S. Forti, G. Ferrari, and A. Brogi, “Secure Cloud-Edge Deployments, with Trust,” Future Gener. Comput. Syst., vol. 102, pp. 775–788, 2020

    2020

  35. [43]

    Automated generation of management workflows for applications based on deployment models,

    L. Harzenetter, U. Breitenb¨ ucher, F. Leymann, K. Saatkamp, B. Weder, and M. Wurster, “Automated generation of management workflows for applications based on deployment models,” in EDOC, pp. 216–225, 2019

    2019

  36. [44]

    Coordinating computation at the edge: a decentralized, self- organizing, spatial approach,

    R. Casadei and M. Viroli, “Coordinating computation at the edge: a decentralized, self- organizing, spatial approach,” in FMEC 2019, pp. 60–67, 2019. 32 Antonio Brogi ∗ et al

    2019

  37. [45]

    Partitioned integration and coordina- tion via the self-organising coordination regions pattern,

    D. Pianini, R. Casadei, M. Viroli, and A. Natali, “Partitioned integration and coordina- tion via the self-organising coordination regions pattern,” Future Gener. Comput. Syst., vol. 114, pp. 44–68, 2021

    2021

  38. [46]

    From field-based coordination to aggregate computing,

    M. Viroli, J. Beal, F. Damiani, G. Audrito, R. Casadei, and D. Pianini, “From field-based coordination to aggregate computing,” in COORDINATION 2018, vol. 10852, pp. 252– 279, Springer, 2018

    2018

  39. [47]

    Modeling and Simulation Tools for Fog Computing–A Comprehensive Survey from a Cost Perspective,

    S. V. Margariti, V. V. Dimakopoulos, and G. Tsoumanis, “Modeling and Simulation Tools for Fog Computing–A Comprehensive Survey from a Cost Perspective,” Future Internet, vol. 12, no. 5, p. 89, 2020

    2020

  40. [48]

    iFogSim: A toolkit for mod- eling and simulation of resource management techniques in the Internet of Things, Edge and Fog computing environments,

    H. Gupta, A. Vahid Dastjerdi, S. K. Ghosh, and R. Buyya, “iFogSim: A toolkit for mod- eling and simulation of resource management techniques in the Internet of Things, Edge and Fog computing environments,” Soft. Pract. Exp., vol. 47, no. 9, pp. 1275–1296, 2017

    2017

  41. [49]

    EdgeCloudSim: An environment for performance evaluation of edge computing systems,

    C. Sonmez, A. Ozgovde, and C. Ersoy, “EdgeCloudSim: An environment for performance evaluation of edge computing systems,” Trans. Emerg. Telecommun. Technol., vol. 29, no. e3493, 2018

    2018

  42. [50]

    Simulating FogDirector Application Management,

    S. Forti, A. Pagiaro, and A. Brogi, “Simulating FogDirector Application Management,” Simul. Model. Pract. Theory, vol. 101, no. 102021, pp. 1–18, 2020

    2020

  43. [51]

    Adaptive task allocation for multi-uav systems based on bacteria foraging be- haviour,

    H. A. Kurdi, M. F. Aldaood, S. Al-Megren, E. Aloboud, A. S. Aldawood, and K. Youcef- Toumi, “Adaptive task allocation for multi-uav systems based on bacteria foraging be- haviour,” Appl. Soft Comput., vol. 83, 2019

    2019

  44. [52]

    Applications and evaluations of bio-inspired approaches in cloud security: A review,

    M. M. Ahsan, K. D. Gupta, A. K. Nag, S. Pouydal, A. Z. Kouzani, and M. P. Mahmud, “Applications and evaluations of bio-inspired approaches in cloud security: A review,” IEEE Access, 2020

    2020

  45. [53]

    Bacteria-inspired communication mechanism based on software-defined network,

    Y.-C. Chang, W.-X. Cai, and J.-W. Jhuang, “Bacteria-inspired communication mechanism based on software-defined network,” in WOCC, pp. 1–3, 2018

    2018

  46. [54]

    Bacteria-inspired network for 5g mobile communication,

    H. Chao, H. Cho, T. K. Shih, and C. Chen, “Bacteria-inspired network for 5g mobile communication,” IEEE Netw., vol. 33, no. 4, pp. 138–145, 2019

    2019

Pith tools

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