{"id":"1c4c0748-2999-419c-8139-53e705d3d3ae","arxiv_id":"1908.01526","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"EdgeMORE models edge resource allocation as an ILP where each tenant declares multiple service options, and shows that more options increase the operator's achievable utility.","lead":"This paper proposes EdgeMORE, an integer linear program that lets a network operator choose among multiple service configurations when allocating edge computing resources to tenants. The authors report that offering more configuration options can increase operator utility, but the result is largely a mathematical consequence of the optimization model rather than an empirical discovery.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 60% utility gain in Sec. VI-B is an artifact of comparing a J=8 optimum against a randomly drawn single option per SP; the single-option baseline is not established as the right counterfactual for non-adaptive services.","rationale":"The reader recommends CONDITIONAL, and I agree that the ILP is valid and that the headline numerical result needs better validation. My stress-test identifies a more specific and more directly load-bearing flaw than the truthfulness assumption: the J=1 baseline in Fig. 3 is a random draw, not a realistic best single configuration. Because Eq. (6) assigns each option an independent random utility, increasing J from 1 to 8 is partly just taking the maximum over more random draws, which increases the expected optimum even if adaptability has no real value. The truthfulness issue flagged by the reader is legitimate, but it is a standard assumption in optimization-based allocation and is a secondary concern compared with the fairness of the baseline used to produce the central 60% figure. The proposed check would settle the matter by re-running the open-source simulation with a best-single-option counterfactual. Since the reader already conditioned the verdict on stronger validation, my finding reinforces the CONDITIONAL status rather than moving it, so the verdict is unchanged.","tokens_in":8657,"tokens_out":10063,"duration_ms":117069,"concrete_test":"Using the open-source EdgeMORE simulation, re-run the Fig. 3 experiment with a best-single-option baseline: for each SP, generate the same J=8 option set, but for the J=1 case declare only the option with the highest u_i,j among those eight options (or, alternatively, the option maximizing utility per unit of normalized resource use). Compare the ILP utility at J=8 against this baseline. If the ratio drops substantially below 1.6, the claimed 60% gain is an artifact of the random single-option baseline rather than a robust property of service adaptability.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central numerical claim rests on Fig. 3, where utility at J=8 is compared with utility at J=1. In the simulation, each option's resource requirements and utility (Eq. 6) are independent random draws, so the J=1 case is one random configuration per SP, while J=8 is the best of eight random configurations per SP. The gain of about 1.6 therefore conflates the value of service adaptability with the order-statistic effect of taking the maximum over more i.i.d. samples. A non-adaptive service in the 'classic' scenario would not run a random configuration; it would run a specific configuration, plausibly one chosen to be favorable to the SP or the NO. The paper does not defend why the random single-option draw is the correct baseline, and the conclusion that 'all approaches adopted in the literature lose the opportunity to gain 60% of utility' is correspondingly overstated. The ILP formulation itself appears sound and the code is open-source, so the concern is directly testable. The reader's separate point about truthful tenant declarations is also real, but the baseline issue is the first load-bearing obstacle for the headline quantitative claim.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes EdgeMORE, a resource-allocation strategy for edge computing in which each service provider (SP) declares several possible configuration options, each with container-level resource requirements and a utility value for the network operator (NO). The NO runs an integer linear program (Sec. V, Eqs. (1)–(4)) that selects at most one option per SP and places the corresponding containers on edge nodes subject to multi-dimensional capacity constraints. The authors argue that this \"service elasticity\" improves NO utility relative to the classic single-option allocation. The numerical evaluation (Sec. VI) reports that going from one to eight options per SP increases utility by a factor of about 1.6, or roughly 60%, and that this gain is available to EdgeMORE but lost by previous approaches. The paper also describes a reference architecture based on Netflix's Open Connect Appliances and provides open-source code for the ILP and simulations.","tokens_in":8875,"tokens_out":4850,"duration_ms":54097,"significance":"If the reported gain were established, the paper would make a useful practical point: service adaptability can increase the utility of a fixed stock of edge resources without adding physical capacity. The ILP formulation (Sec. V) is clean and addresses a relevant problem that combines option selection, multi-dimensional resource constraints, and container placement. The open-source implementation is a strength, since it makes the experiments reproducible and the central evaluation claim directly testable. However, the main quantitative claim is not yet convincing. The observed improvement is largely a necessary consequence of the optimization formulation---enlarging the option set enlarges the feasible set of (1)–(4), so the optimal value cannot decrease---and the chosen baseline (a random single option) is not a realistic model of a non-adaptive service. The paper is therefore better viewed as a formulation/architecture contribution whose headline performance benefit needs to be re-validated against a defensible baseline and a sensitivity analysis.","major_comments":[{"comment":"The headline 60% utility gain is not an empirical measurement of the benefit of service adaptability; it is an order-statistic artifact of the optimization model. In the simulation, each option's resource requirements and utility are generated independently at random (Sec. VI-A), so the J=1 case is a single random configuration per SP, while J=8 is the best of eight random configurations per SP. Since the optimal value of the ILP in (1)–(4) is non-decreasing in the number of declared options by construction, the increase from J=1 to J=8 is a necessary property of the model rather than evidence that EdgeMORE captures a previously lost opportunity. A non-adaptive service would not run a random configuration; it would run a specific, likely favorable configuration. The authors should compare against a deterministic single-option baseline (e.g., each SP's highest-utility feasible configuration, or a fixed configuration reflecting current practice) and report the gain relative to that baseline. As written, the conclusion that \"all approaches adopted in the literature lose the opportunity to gain 60% of utility\" is not justified by Fig. 3.","section":"Sec. VI-B, Fig. 3"},{"comment":"The quantitative result depends on several arbitrary synthetic choices: the load factor K=1.8, the uniform demand distributions, and the random exponents and weights in the utility formula (6). No sensitivity analysis is reported for K, for the utility model, or for the demand distribution. Figure 4 only scales the cluster while keeping K fixed, so it does not test sensitivity to the load factor. The paper's own caveat that real datasets are unavailable is reasonable, but it means the numerical 60% figure cannot be treated as a general result. At minimum, the authors should vary K and the utility parameters and show how the gain changes; otherwise the central claim is tied to a single arbitrary configuration of the simulator.","section":"Sec. VI-A, Eqs. (5)–(6)"},{"comment":"The model assumes that each SP truthfully and completely declares every viable configuration option, the exact resources each container needs, and the utility each option provides to the NO. The paper does not discuss what happens if an SP under-reports utilities, hides options, or inflates resource requirements to influence the allocation, nor does it propose any verification or incentive mechanism. This assumption is outside the optimization core, but it is load-bearing for the practical claim that a NO can increase its utility by adopting EdgeMORE: if declarations are not dependable, the ILP's optimum is computed on inputs that may not reflect reality. The authors should either justify the assumption (e.g., by stating a trust model or a contractual setting) or discuss robustness and incentive issues as an explicit limitation.","section":"Secs. III and IV-B"}],"minor_comments":[{"comment":"The upper limit of the second summation is written as Ni, but the parameter for the number of options of SP i is defined as Ji in Sec. III; the objective should sum j=1..Ji.","section":"Eq. (1)"},{"comment":"The constraint is written for l=1..2, which contradicts the general definition of L resource types in Sec. III. It should be l=1..L.","section":"Eq. (3)"},{"comment":"The summation notation in constraint (4) should explicitly be over j=1..Ji for each i, to be consistent with the rest of the formulation.","section":"Eq. (4)"},{"comment":"The sentence \"the utility has a gain almost equal to 1.6\" is ambiguous: is this a ratio, a difference, or a percentage-point increase? The subsequent phrase \"gain 60% of utility\" suggests a 1.6x ratio, but the units should be stated precisely.","section":"Sec. VI-B"},{"comment":"The text says results are averaged across 20 runs and that 95% percentiles are reported, but the figure captions do not state which quantity is shown or where the percentiles are marked. Please make the plot semantics explicit.","section":"Sec. VI, intro"},{"comment":"The claim that the naive allocation uses ~3.3 times the resources of EdgeMORE is not defined: does \"resources\" mean total CPU plus RAM, a weighted sum, or something else? Please define the metric and report its variability across runs.","section":"Sec. VI-B"},{"comment":"Reference [12] cites \"Josilo and Dan\" without full author names; the intended citation appears to be Jošilo and Dán. Also, in Sec. IV-B, \"Smarm configuration files\" should be \"Swarm configuration files.\"","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The core ILP and architecture are reasonable, and the open-source code is a genuine strength, but the paper's central numerical claim is currently an artifact of comparing the maximum over J i.i.d. random draws with a single random draw. This is fixable within the manuscript's scope by re-validating against a deterministic single-option baseline and adding a sensitivity analysis, but the headline conclusion must be substantially rewritten. I would also encourage the editor to ask the authors to clearly state that the improvement is a property of expanding the feasible set in (1)–(4), not an independent empirical discovery."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper's real contribution is the ILP formulation (Sec. V) for multi-tenant, multi-node, multi-resource edge allocation where each tenant declares multiple runnable configurations. That combination is new, and the authors honestly map it onto known knapsack problems. The code is open-source, and the constraints (2)-(4) are coherent; the only typo is the index mismatch in Eq. (3) (sum over Ni and l=1..2 should be Ji and L). So if you need a clean formal baseline for option-aware allocation, this is a useful reference.\n\nThe soft spot is the headline claim. Section VI-B reports that going from 1 to 8 options per SP yields roughly a 60% utility gain, and concludes that all prior work misses this. But in their simulation, each option's resource requirements and utility are independent random draws. So the J=8 case is the best of eight i.i.d. samples, while J=1 is a single random sample. A non-adaptive service would not run a random configuration; it would run one deliberately chosen configuration. The comparison conflates service adaptability with the order-statistic effect of taking a maximum over more samples. That is a real flaw, and it is directly testable because the code is available. The monotonicity of utility with J is also a logical consequence of the feasible-set expansion, so presenting it as a simulation result is circular. These two issues undercut the quantitative claim, not the ILP itself.\n\nThe truthful-declaration assumption (Sec. III) is a genuine practical concern, but secondary. The evaluation is entirely synthetic, with a load factor K=1.8 and no baseline beyond the naive random allocator. Computation times in Fig. 4 are acknowledged to be too high for responsive re-allocation.\n\nWho should read this: anyone working on edge resource allocation who wants a formal statement of the multi-option problem. The paper is not a breakthrough, but the formulation and code are solid enough to build on. I would send it to peer review, but the revision needs to fix the baseline, reframe the monotonicity result as a property of the model, and be honest about the magnitude of gains.","headline":"Worth a serious look for the ILP and problem framing, but the headline 60% gain is an artifact of comparing the best of eight random options against one random option.","tokens_in":9395,"tokens_out":2436,"would_cite":false,"duration_ms":23588,"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":"This paper claims that letting edge-computing tenants declare several feasible configurations, then choosing one per tenant via integer linear programming, raises operator utility by about 60% over the standard single-option baseline.","keywords":["edge computing","resource allocation","service elasticity","integer linear programming","multi-tenant systems","container placement","utility maximization","knapsack problem"],"falsifier":"Run EdgeMORE on a real edge cluster with containerized services whose options are actual deployment variants and whose utility is measured from traffic saved or latency reduced, comparing one declared option per service against eight; if the realized utility gain falls far below the simulated ~60% or disappears under incomplete or inaccurate declarations, the central claim fails.","tokens_in":8448,"feed_emoji":"📈","tokens_out":8586,"duration_ms":79157,"temperature":0.7,"pith_summary":"In edge computing, a network operator owns scarce resources and third-party services rent them. This paper claims that letting each service declare several feasible configurations, and having the operator choose the single best option per service, can raise total operator utility by a factor of about 1.6 over the standard one-configuration-per-service approach. The gain comes from service adaptability: a streaming service, for instance, can trade storage for CPU by repackaging video on the fly, so different allocations of the same edge resources yield different value. If the claim holds, an operator can improve utility without buying more hardware, purely by exploiting flexibility already present in modern containerized services. The paper formalizes the choice as an integer linear program and tests it in simulation.","feed_headline":"Multiple tenant options lift edge-computing utility by 60%","feed_subtitle":"The same physical resources yield more value when tenants can run in several configurations.","key_machinery":"The carrying machinery is the option list plus the EdgeMORE integer linear program: binary variables $x_{i,j}$ choose option $j$ of service $i$, binary variables $y_{i,j}^{z,m}$ place container $z$ of that option on node $m$, and constraints tie placement to selection, cap CPU and RAM on every node, and allow at most one option per service. The objective maximizes the sum of declared per-option utilities $u_{i,j}$. This couples option selection with container placement in one optimization, which is why random selection and placement performs poorly.","core_discovery":"The central discovery is that the number of configuration options offered per tenant is itself a lever on allocation quality. In the simulated edge cluster with 50 services, eight containers per option, and CPU/RAM capacities, raising the declared options per service from 1 to 8 increases the operator's achieved utility by a factor of about 1.6 (a ~60% gain), while a naive random selection and placement uses about 3.3 times the resources for lower utility. The ILP selects at most one option per service and places every container of the chosen option so that no node exceeds its CPU or memory capacity, maximizing the sum of declared per-option utilities. The comparison is against the standard assumption of one monolithic configuration per service, which the paper identifies as the common approach in prior work.","pith_inferences":["Putting option declaration in the hands of self-interested tenants raises an incentive problem the paper does not address: a tenant may omit low-value options or inflate declared utilities, so a deployment would need auditing or incentive-compatible reporting to keep the ILP's solution meaningful.","The 60% figure comes from synthetic concave utility functions, so a real deployment should measure realized utility (traffic saved, latency, cost) to see whether the gain survives real option catalogs.","The selection-plus-placement structure generalizes to any multi-tenant resource pool where one workload can run in several footprints, such as serverless functions or GPU clusters, making multiple-option declaration a general allocation lever rather than an edge-computing-specific trick."],"forward_implications":["An operator can capture roughly 60% more utility from the same edge hardware simply by asking tenants to declare multiple viable configurations and optimizing the choice.","The plotted utility rises as the number of options per service grows from 1 to 8, so the benefit is tied to how much service flexibility tenants can actually express.","The same ILP handles multiple resource dimensions, multiple nodes, and microservice containers, so the multiple-option idea is not restricted to storage or bandwidth allocation.","Since the problem generalizes multidimensional knapsack, exact solution is computationally expensive, and fast heuristics will be needed before the scheme can support dynamic reallocation.","In the paper's simulations the utility result is insensitive to cluster scale, which suggests the gain is not tied to one particular cluster size."],"supporting_citations":[{"why":"Supplies the concrete video transcoding-and-caching example that motivates why a single service can run in several resource configurations.","marker":"[2]"},{"why":"Provides the prior multi-resource QoS allocation formulation and the assumption that each configuration carries a utility to the operator.","marker":"[14]"},{"why":"Identifies the single-node version of the problem as a multidimensional multiple-choice knapsack problem, fixing the problem class.","marker":"[26]"},{"why":"Documents knapsack hardness and the absence of fully polynomial approximation schemes, motivating the exact ILP and future heuristics.","marker":"[27]"},{"why":"Provides the open-source ILP and simulation code used to produce the reported utility-gain results.","marker":"[28]"}],"fun_headline_variants":["EdgeMORE: tenant config options boost edge utility 60%","Letting tenants pick configs: 60% more edge utility","Multiple options per tenant: key to edge resource gains","Simulation: 8 deployment options lift edge utility 1.6x"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that service providers truthfully report every viable configuration, the exact resources each container needs, and the utility each option gives the operator, so the ILP optimum is only as meaningful as those declarations.","fun_headline_variants_meta":{"raw":{"variants":["EdgeMORE: tenant config options boost edge utility 60%","Letting tenants pick configs: 60% more edge utility","Multiple options per tenant: key to edge resource gains","Simulation: 8 deployment options lift edge utility 1.6x"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000795,"raw_usage":{"total_tokens":3518,"prompt_tokens":982,"completion_tokens":2536,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":598,"completion_tokens_details":{"reasoning_tokens":2462}},"tokens_in":598,"tokens_out":2536,"duration_ms":18506,"temperature":1.0,"reasoning_tokens":2462,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T15:10:04.348503+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run EdgeMORE on a real edge cluster with containerized services whose options are actual deployment variants and whose utility is measured from traffic saved or latency reduced, comparing one declared option per service against eight; if the realized utility gain falls far below the simulated ~60% or disappears under incomplete or inaccurate declarations, the central claim fails.","supporting_citations":[{"cited_title":"Optimal Transcoding and Caching for Adaptive Streaming in Media Cloud,","cited_arxiv_id":null,"evidence_quote":"Supplies the concrete video transcoding-and-caching example that motivates why a single service can run in several resource configurations."},{"cited_title":"A scalable solution to the multi-resource QoS problem,","cited_arxiv_id":null,"evidence_quote":"Provides the prior multi-resource QoS allocation formulation and the assumption that each configuration carries a utility to the operator."},{"cited_title":"Solving the multidimensional multiple-choice knapsack problem by constructing convex hulls,","cited_arxiv_id":null,"evidence_quote":"Identifies the single-node version of the problem as a multidimensional multiple-choice knapsack problem, fixing the problem class."},{"cited_title":"Kellerer, U","cited_arxiv_id":null,"evidence_quote":"Documents knapsack hardness and the absence of fully polynomial approximation schemes, motivating the exact ILP and future heuristics."},{"cited_title":"EdgeMORE Repository,","cited_arxiv_id":null,"evidence_quote":"Provides the open-source ILP and simulation code used to produce the reported utility-gain results."}],"review_version":1}