Pith. sign in

REVIEW 3 major objections 7 minor 30 references

EdgeMORE: Improving Resource Allocation with Multiple Options from Tenants

T0 review · 3 major / 7 minor · reviewed 2026-08-14 · deepseek-v4-flash

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

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 1908.01526 v3 pith:LZG5QMX7 submitted 2019-08-05 cs.DC

Andrea Araldo , Alessandro Di Stefano , Antonella Di Stefano This is my paper · ORCID
classification cs.DC
keywords edgecomputingresourceallocationserviceelasticityintegerlinearprogrammingmulti-tenantsystemscontainerplacementutilitymaximizationknapsackproblem
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

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

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

  • 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.
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

3 major / 7 minor

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.

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 (3)
  1. [Sec. VI-B, Fig. 3] 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.
  2. [Sec. VI-A, Eqs. (5)–(6)] 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.
  3. [Secs. III and IV-B] 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.
minor comments (7)
  1. [Eq. (1)] 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.
  2. [Eq. (3)] 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.
  3. [Eq. (4)] 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.
  4. [Sec. VI-B] 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.
  5. [Sec. VI, intro] 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.
  6. [Sec. VI-B] 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.
  7. [References] 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."

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the reported utility gain is a consequence of the stated optimization model and simulated random scenario, not a fitted input renamed as a prediction.

full rationale

The paper's central claim is that allowing SPs to declare multiple configuration options and then optimizing over them raises the NO's utility. The ILP in Sec. V maximizes the sum of declared utilities (Eq. 1) subject to per-SP single-option selection (Eq. 4) and capacity constraints (Eq. 3). It is mathematically true that enlarging the option set cannot lower the optimal value, but the paper does not present this monotonicity as an external prediction; it presents a quantitative simulation outcome (the 1.6x gain) generated from explicitly random utility and resource draws (Eqs. 5-6). No parameter is fitted to any target result, and the single-option baseline is not an optimized fit; it is one random configuration per SP at J=1. The utility model is imported from cited literature as an explicit modeling assumption, not derived from the conclusion. Self-references [1] and [30] are background and future-work mentions and are not load-bearing. Concerns about whether the random single-option baseline represents real non-adaptive services are experimental-design or correctness risks, not circularity. The derivation chain is self-contained and transparent.

Assumptions & free parameters 1 free parameters · 5 assumptions · 0 invented entities

The central claim rests on domain assumptions about truthful tenant declarations, additive utility, static resource usage, and optimal ILP execution, rather than on invented physical entities. The only hand-chosen numerical input in the evaluation is the load factor K=1.8.

free parameters (1)
  • Load factor K = 1.8
    Hand-chosen in Sec. VI-a to set average demand at 1.8x total edge capacity in the synthetic scenarios; the magnitude of the reported utility gain depends on this choice.
assumptions (5)
  • domain assumption Each tenant SP can enumerate all viable configuration options, each with exact resource requirements and an accurate utility value for the NO, and reports them truthfully.
    Core to the model in Sec. III and the Edge Master workflow in Sec. IV-C; if declarations are coarse or strategic, the ILP solution is not meaningful.
  • domain assumption NO utility is additive over SPs and known a priori as ui,j.
    Objective (1) sums per-option utilities with no per-container utility or coupling between tenants.
  • domain assumption Resource consumption of each container is static and known at the start of each time slot (snapshot model).
    Sec. III states time is divided into slots and all quantities are known at slot start, ignoring runtime dynamics and inter-container communication.
  • domain assumption The ILP can be solved to optimality within the allocated time slot.
    Sec. VI-d reports computation time may be too high for responsive allocation, but the evaluation assumes optimal solutions are computed.
  • domain assumption Service utility is a concave increasing function of allocated resources.
    Used only to synthesize utility in Eq. (6) for the simulation, following [1], [7], [14]; not needed for the ILP itself.

how reviews work

0 comments
Cite this review

Pith. "Pith review of EdgeMORE: Improving Resource Allocation with Multiple Options from Tenants." pith.science (2026). https://pith.science/paper/LZG5QMX7

@misc{pith2026190801526,
  author       = {Pith},
  title        = {Pith review of: EdgeMORE: Improving Resource Allocation with Multiple Options from Tenants},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LZG5QMX7}},
  note         = {Machine review of arXiv:1908.01526}
}
read the original abstract

Under the paradigm of Edge Computing (EC), a Network Operator (NO) deploys computational resources at the network edge and let third-party Service Providers (SPs) run on top of them, as tenants. Besides the clear advantages for SPs and final users thanks to the vicinity of computation nodes, a NO aims to allocate edge resources in order to increase its own utility, including bandwidth saving, operational cost reduction, QoE for its users, etc. However, while the number of third-party services competing for edge resources is expected to dramatically grow, the resources deployed cannot increase accordingly, due to physical limitations. Therefore, smart strategies are needed to fully exploit the potential of EC, despite its constrains. To this aim, we propose to leverage service adaptability, a dimension that has mainly been neglected so far: each service can adapt to the amount of resources that the NO has allocated to it, balancing the fraction of service computation performed at the edge and relying on remote servers, e.g., in the Cloud, for the rest. We propose EdgeMORE, a resource allocation strategy in which SPs express their capabilities to adapt to different resource constraints, by declaring the different configurations under which they are able to run, specifying the resources needed and the utility provided to the NO. The NO then chooses the most convenient option per each SP, in order to maximize the total utility. We formalize EdgeMORE as a Integer Linear Program. We show via simulation that EdgeMORE greatly improves EC utility with respect to the standard where no multiple options for running services are allowed.

Figures

Figures reproduced from arXiv: 1908.01526 by the authors.

Figure 1
Figure 1. Netflix architecture for OCAs CDN in a certain node m cannot exceed its capacity cl,m, for any resource type l = 1, . . . , L. Therefore, the NO must optimally choose one option per SP, trading off utility and resource consumption and, at the same time, optimally place the containers of the chosen options in the available Edge nodes, without exceeding their capacities. Note that we do not define a per-container util… view at source ↗
Figure 2
Figure 2. Overview of the proposed architecture. SPs run part of their service [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Benefits of multiple options. shows that careful option selection and container placement is of paramount importance. c) Insensitivity to cluster scaling: In [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Insensitivity to cluster scaling VII. CONCLUSION AND FUTURE WORK This paper presented EdgeMORE, a strategy for resource allocation for Edge Computing (EC), where tenants are third party Service Providers (SPs). The novelty of this work is that it exploits service elast…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

30 extracted references · 30 canonical work pages

  1. [1]

    Caching encrypted content via stochastic cache partitioning,

    A. Araldo, G. D ´an, and D. Rossi, “Caching encrypted content via stochastic cache partitioning,” IEEE/ACM Trans. Netw. , vol. 26, no. 1, pp. 548–561, Feb 2018

    work page 2018

  2. [2]

    Optimal Transcoding and Caching for Adaptive Streaming in Media Cloud,

    Y . Jin, Y . Wen, and C. Westphal, “Optimal Transcoding and Caching for Adaptive Streaming in Media Cloud,” IEEE Trans. Circ. and Sys. Video Tech., vol. 25, no. 12, pp. 1914–1925, 2015

    work page 1914

  3. [3]

    Comprehensive cybersecurity defenses for con- tent delivery,

    Limelight Networks, “Comprehensive cybersecurity defenses for con- tent delivery,” Limelight Networks, Tech. Rep., 2018

    work page 2018

  4. [4]

    Containers and Clusters for Edge Cloud Architec- tures – a Technology Review,

    C. Pahl and B. Lee, “Containers and Clusters for Edge Cloud Architec- tures – a Technology Review,” in IEEE FiCloud2 , 2015

    work page 2015

  5. [5]

    Comparison of edge computing implemen- tations: Fog computing, cloudlet and mobile edge computing,

    K. Dolui and S. K. Datta, “Comparison of edge computing implemen- tations: Fog computing, cloudlet and mobile edge computing,” 2017 Global Internet of Things Summit (GIoTS) , pp. 1–6, 2017

    work page 2017

  6. [6]

    Experimental Testbed for Edge Computing in Fiber-Wireless Broadband Access Networks,

    B. P . Rimal, M. Maier, and M. Satyanarayanan, “Experimental Testbed for Edge Computing in Fiber-Wireless Broadband Access Networks,” IEEE Commun. Mag. , vol. 56, no. 8, pp. 160–167, 2018

    work page 2018

  7. [7]

    Joint cache resource allocation and request routing for in-network caching services,

    W. Chu, M. Dehghan, J. C. Lui, D. Towsley, and Z. L. Zhang, “Joint cache resource allocation and request routing for in-network caching services,” Computer Networks , vol. 131, pp. 1–14, 2018

    work page 2018

  8. [8]

    A hierarchical edge cloud architecture for mobile computing,

    L. Tong, Y . Li, and W. Gao, “A hierarchical edge cloud architecture for mobile computing,” in IEEE INFOCOM , 2016

    work page 2016

Show all 30 references
  1. [9]

    Inferring streaming video quality from encrypted traf fi c: Practical models and deployment experience,

    P . Schmitt, F. Bronzino, S. Ayoubi, G. Martins, R. Teixeira, and N. Feamster, “Inferring streaming video quality from encrypted traf fi c: Practical models and deployment experience,” 2019

    2019

  2. [10]

    Net- work Slicing Games: Enabling Customization in Multi-Tenant Mobile Networks,

    P . Caballero, A. Banchs, G. De V eciana, and X. Costa-Perez, “Net- work Slicing Games: Enabling Customization in Multi-Tenant Mobile Networks,” IEEE/ACM Trans. Net. , vol. 27, no. 2, pp. 662–675, 2019

    2019

  3. [11]

    Joint Network Slicing and Mobile Edge Computing in 5G Networks,

    B. Xiang, J. Elias, F. Martignon, and E. D. Nitto, “Joint Network Slicing and Mobile Edge Computing in 5G Networks,” in IEEE ICC , 2019

    2019

  4. [12]

    Wireless and computing resource allocation for sel fi sh computation offl oading in edge computing,

    Josilo and Dan, “Wireless and computing resource allocation for sel fi sh computation offl oading in edge computing,” in IEEE INFOCOM , 2019

    2019

  5. [13]

    Adaptive Federated Learning in Resource Constrained Edge Computing Systems,

    S. Wang et al. , “Adaptive Federated Learning in Resource Constrained Edge Computing Systems,” IEEE JSAC , vol. 37, no. 6, 2019

    2019

  6. [14]

    A scalable solution to the multi-resource QoS problem,

    C. Lee et al. , “A scalable solution to the multi-resource QoS problem,” in IEEE Real Time Systems Symp. , 1999

    1999

  7. [15]

    Capturing resource tradeoffs in fair multi-resource allocation,

    D. Zarchy et al. , “Capturing resource tradeoffs in fair multi-resource allocation,” in IEEE INFOCOM , 2015

    2015

  8. [16]

    Dynamic cpu resource allocation in containerized cloud environments,

    J. Monsalve, A. Landwehr, and M. Taufer, “Dynamic cpu resource allocation in containerized cloud environments,” in 2015 IEEE Int. Conf. on Cluster Computing , Sep. 2015, pp. 535–536

    2015

  9. [17]

    Dynamic resource allocation algorithm for container-based service computing,

    Y . Tao, X. Wang, X. Xu, and Y . Chen, “Dynamic resource allocation algorithm for container-based service computing,” in IEEE Int. Symp. on Autonomous Decentralized System (ISADS) , March 2017

    2017

  10. [18]

    Container oriented job scheduling using linear pro- gramming model,

    D. Zhang et al. , “Container oriented job scheduling using linear pro- gramming model,” in ICIM, 2017

    2017

  11. [19]

    Resource management with deep reinforcement learn- ing,

    H. Mao et al. , “Resource management with deep reinforcement learn- ing,” in ACM HotNets . ACM, 2016

    2016

  12. [20]

    A popularity-based approach for effective cloud offl oad in fog deployments,

    M. Enguehard et al. , “A popularity-based approach for effective cloud offl oad in fog deployments,” in ITC, vol. 01, Sep. 2018, pp. 55–63

    2018

  13. [21]

    [Online]

    Openconnect service by net fl ix. [Online]. Available: https://openconnect.netfl ix.com/en/

  14. [22]

    [On- line]

    Resource usage monitoring on kubernetes. [On- line]. Available: https://kubernetes.io/docs/tasks/debug-application- cluster/resource-usage-monitoring/

  15. [23]

    When https meets cdn: A case of authentication in delegated service,

    J. Liang et al. , “When https meets cdn: A case of authentication in delegated service,” in IEEE Symp. on Security and Privacy , May 2014

    2014

  16. [24]

    A note on the set union knapsack problem,

    A. Arulselvan, “A note on the set union knapsack problem,” Discrete Applied Mathematics , vol. 169, pp. 214 – 218, 2014

    2014

  17. [25]

    A novel binary arti fi cial bee colony algorithm for the set-union knapsack problem,

    Y . He, H. Xie, T.-L. Wong, and X. Wang, “A novel binary arti fi cial bee colony algorithm for the set-union knapsack problem,” Future Generation Computer Systems , vol. 78, pp. 77 – 86, 2018

    2018

  18. [26]

    Solving the multidimensional multiple-choice knapsack problem by constructing convex hulls,

    M. M. Akbar et al. , “Solving the multidimensional multiple-choice knapsack problem by constructing convex hulls,” Comp. & Op. Res. , vol. 33, no. 5, pp. 1259 – 1273, 2006

    2006

  19. [27]

    Kellerer, U

    H. Kellerer, U. Pferschy, and D. Pisinger, Knapsack Problems , 1st ed. Springer, 2004

    2004

  20. [28]

    EdgeMORE Repository,

    A. Di Stefano, “EdgeMORE Repository,” https://github.com/aleskandro/cloud-edge-offl oading

  21. [29]

    Scalable resource allocation for multi-processor QoS optimization,

    S. Ghosh, R. Rajkumar, J. Hansen, and J. Lehoczky, “Scalable resource allocation for multi-processor QoS optimization,” in IEEE ICDCS, 2003

    2003

  22. [30]

    Coope4m: A deployment framework for communication-intensive applications on mesos,

    A. Di Stefano, A. Di Stefano, G. Morana, and D. Zito, “Coope4m: A deployment framework for communication-intensive applications on mesos,” in 2018 IEEE 27th Int. Conf. on Enabling Technol.: Infrastruc- ture for Collaborative Enterprises (WETICE) , June 2018, pp. 36–41. 6

    2018

Pith tools

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