{"id":"f846c7c4-b4a5-48f8-a0ac-da9796d0a5e7","arxiv_id":"2501.09964","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"MARIO2 is a bacteria-inspired, fully decentralized, declarative fog application manager whose Prolog policies steer replication, migration, and undeployment using only locally available data, validated by simulation.","lead":"The authors extend their earlier MARIO system into MARIO2, a fully decentralized, declarative (Prolog-based) manager that can replicate, migrate, or undeploy application instances based only on local data. They test four management policies in a simulated fog network with Rome taxi mobility traces and report fast convergence after user handovers.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Rule (r1) enacts all accepted requests in parallel but leaves node acceptance Pn unspecified, so concurrent replications can over-commit a node; the simulations avoid this only by implicit sequential arbitration.","rationale":"The paper's central claim has two parts: the solution is fully decentralised and declarative, and it is scalable and flexible enough for opportunistic Cloud-IoT, as validated by simulations with user mobility. For the claim to hold, a decentralised system's management decisions must be correct even when agents act concurrently, and the evidence must actually exercise the decentralised mechanism. The reader's weakest assumption targets exactly this: the formal rule (r1) in §2.2 enacts every accepted request in parallel, but the acceptance policy Pn is left as an uninterpreted predicate of a single request. Nothing in the model prevents two accepted requests from jointly exceeding a node's capacity. This is not a matter of tuning; it is an under-specification of the semantics. The published Prolog policies are request-generation rules; they do not specify target-node admission control. The YAFS implementation appears to evaluate all pending requests in one MARIO2 process, and if it updates available hardware after each accepted request it is performing a centralised serialisation that the formal model does not describe. That discrepancy undermines the validation as evidence for the fully-decentralised, parallel claim.\n\nA secondary weakness is the scalability evidence: Section 4.4 argues scalability analytically from locality and parallelism, but the experiments use one fixed topology (85 nodes, 51 users, 6 apps) and do not vary scale. If the capacity/parallelism issue is fixed, the scalability claim would still need a scaling experiment. I do not treat the absence of baselines/error bars as a correctness flaw; the simulation is well described and the artifact is open source.\n\nI agree with the reader's conditional verdict. The concern is concrete and testable by replaying a management cycle under true batch-parallel semantics. If overcommit appears, the formal model is unsound as stated and the simulation's sequential arbitration is the reason the reported results look stable; the paper would need to either specify a distributed admission-control policy or temper the 'fully decentralised' claim. If overcommit does not appear, the code has an implicit mechanism that should be documented, and the remaining issue is only the missing scaling validation.","tokens_in":20839,"tokens_out":7241,"duration_ms":74149,"concrete_test":"Inspect the MARIO2/YAFS code in the MarioII branch to identify how node acceptance is implemented (predicate/function checking AvailableHW) and whether the MARIO2 DES process updates resource availability between requests within one cycle. Then reproduce the Policy 3 TaxiRome scenario with a modified evaluation loop that applies all accepted requests in a batch against the pre-batch resource snapshot, as rule (r1) literally states, and count nodes whose total allocated hardware exceeds their declared AvailableHW (e.g., an AP with 1 unit hosting more than one instance). If such violations occur, the formal semantics permits overcommit and the published simulation masks it; if they do not, the code must contain an implicit atomicity or resource-checking mechanism that should be specified in the paper.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 2.2 defines A = {x | x ∈ R ∧ ∀n ∈ N : Pn(x)} and then states 'Accepted requests A are all enacted in parallel'. Pn is a per-node acceptance predicate over an individual request, not over the batch A or over the future state after other accepted requests are applied. If Pn checks the node's current free hardware (the only resource information the model exposes), two agents in the same management cycle can both request replication into the same node that has just enough free hardware for one, and both pass Pn. Applying both in parallel then over-commits the node. The four Prolog policies in §3.3 define only when an agent triggers an operation; they do not define the target node's acceptance decision, so the gap is not repaired by the policies. The YAFS implementation described in §4.1 has a single MARIO2 DES process that 'periodically evaluates all operation requested by the DES agents' and 'performs or inhibits' them; if that evaluation is sequential, resource state is updated between requests and the second acceptance is rejected, which hides the formal problem. But such sequential arbitration is a centralised mechanism, which is exactly what the paper claims to avoid ('fully decentralised'). The central claim therefore depends on an implicit, unstated capacity-consistency mechanism for concurrent acceptances.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":21022,"tokens_out":3299,"duration_ms":35983,"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":[{"comment":"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.","section":"§2.2, rule (r1)"},{"comment":"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.","section":"§4.1"},{"comment":"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.","section":"§4.3 and Table 2"},{"comment":"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.","section":"§4.4"}],"minor_comments":[{"comment":"There is a typo in the first sentence: 'hterogeneous' should be 'heterogeneous'.","section":"Abstract"},{"comment":"In the text before Policy 2, 'P olicy' should be 'Policy'.","section":"§3.3"},{"comment":"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.","section":"§4.2"},{"comment":"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.","section":"§4.3, first paragraph"},{"comment":"Figure 17b reports 'r = --' without explanation; the caption should state that the correlation coefficient is undefined because one series is constant.","section":"Figures 16–18"}],"recommendation":"major_revision","confidential_remarks":"The paper is an extended journal version of earlier workshop work, and the novelty relative to the authors' previous publication is incremental but sufficient if the identified formal and experimental gaps are addressed. The main point to press is the discrepancy between the formal model, which allows parallel acceptance without a consistency condition, and the simulation implementation, which appears to use a centralised MARIO2 process to arbitrate requests. This discrepancy goes to the heart of the 'fully decentralised' claim and should be resolved before publication."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read it. The genuinely new pieces are a formal operational semantics (thin but real), a reduced local-data model, four Prolog policies, and a YAFS simulation over real taxi traces with user mobility. The code is on GitHub, the policies are clearly spelled out, and the paper shows convergence within 1-2 management cycles after handovers. That is honest progress for decentralised fog management.\n\nThe soft spots are proportionate. The evaluation compares only the four policies to each other. No centralized or other decentralized baseline, no repeated runs or error bars. The scalability claim in Section 4.4 is argumentative: it argues by locality that the approach scales, but there are no experiments with larger topologies. The formal semantics has a real gap: rule (r1) enacts all accepted requests in parallel, but Pn is a per-node predicate over a single request, not over the batch, so two concurrent accepts into the same node can overcommit it. The YAFS implementation avoids this by having a single MARIO2 DES process evaluate requests sequentially, which is centralised arbitration – exactly what the paper claims to avoid. This does not sink the design, but the model and the implementation tell different stories and the paper should reconcile them. Minor: a typo where both app classes are described as 'low capacity'.\n\nWho is this for: researchers in fog/edge management, particularly those interested in declarative policies and decentralised control. It deserves a serious referee because the artifact is real and the approach is plausible; the referee should ask for baseline comparisons, repeated runs, and a batch-aware or transactional acceptance semantics. I'd take it for review with major revisions expected.","headline":"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.","tokens_in":21623,"tokens_out":3360,"would_cite":false,"duration_ms":33141,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A decentralised, declarative controller using only local data - MARIO2 - keeps fog application instances near mobile users within one to two management cycles.","keywords":["fog computing","decentralised application management","declarative programming","bacteria-inspired","user mobility","Cloud-IoT continuum","Prolog","self-organisation"],"falsifier":"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.","tokens_in":1696,"feed_emoji":"🦠","tokens_out":5887,"duration_ms":104950,"temperature":0.7,"pith_summary":"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.","feed_headline":"Bacteria-inspired fog manager follows users in ~1 cycle","feed_subtitle":"Decentralised Prolog agents with only local data rebalance services after handovers in a Rome taxi-traces testbed.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the earlier MARIO model and prototype that MARIO2 extends with a formal semantics, reduced local data, and new policies.","marker":"[15]"},{"why":"The YAFS discrete-event simulator used to run all four policy experiments.","marker":"[16]"},{"why":"Provides the real taxi mobility traces that drive the 51 simulated users and 81 access-point handovers.","marker":"[17]"},{"why":"Supports the claim that centralised placement decision-making is worst-case exponential, motivating the decentralised approach.","marker":"[9]"},{"why":"The decentralised monitoring approach (FogMon) that justifies the assumption that nodes can expose local contextual data to agents.","marker":"[20]"},{"why":"Surveys the centralised state of the art in fog placement that the decentralised solution positions itself against.","marker":"[5]"}],"fun_headline_variants":["Bacteria-inspired fog manager converges in one cycle","Decentralised fog apps: bacteria ops, local data only","Fog management: bacteria-like agents self-organise in one cycle","Memory cuts inhibited fog actions by 80% in decentralised manager","Bacteria-inspired fog: different policies for different app needs"],"cache_read_input_tokens":23680,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Bacteria-inspired fog manager converges in one cycle","Decentralised fog apps: bacteria ops, local data only","Fog management: bacteria-like agents self-organise in one cycle","Memory cuts inhibited fog actions by 80% in decentralised manager","Bacteria-inspired fog: different policies for different app needs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00068,"raw_usage":{"total_tokens":3024,"prompt_tokens":816,"completion_tokens":2208,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":432,"completion_tokens_details":{"reasoning_tokens":2124}},"tokens_in":432,"tokens_out":2208,"duration_ms":15423,"temperature":1.0,"reasoning_tokens":2124,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T19:29:24.512885+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Towards Declarative Decentralised Applica- tion Management in the Fog,","cited_arxiv_id":null,"evidence_quote":"Supplies the earlier MARIO model and prototype that MARIO2 extends with a formal semantics, reduced local data, and new policies."},{"cited_title":"YAFS: A simulator for IoT scenarios in Fog computing,","cited_arxiv_id":null,"evidence_quote":"The YAFS discrete-event simulator used to run all four policy experiments."},{"cited_title":"CRA WDAD dataset roma/taxi (v. 2014-07-17)","cited_arxiv_id":null,"evidence_quote":"Provides the real taxi mobility traces that drive the 51 simulated users and 81 access-point handovers."},{"cited_title":"Continuous reasoning for managing next-gen distributed applica- tions,","cited_arxiv_id":null,"evidence_quote":"Supports the claim that centralised placement decision-making is worst-case exponential, motivating the decentralised approach."},{"cited_title":"Measuring the Fog, Gently,","cited_arxiv_id":null,"evidence_quote":"The decentralised monitoring approach (FogMon) that justifies the assumption that nodes can expose local contextual data to agents."},{"cited_title":"How to Place Your Apps in the Fog: State of the Art and Open Challenges,","cited_arxiv_id":null,"evidence_quote":"Surveys the centralised state of the art in fog placement that the decentralised solution positions itself against."}],"review_version":1}