From 6b1a4b478a6cfc1c525787063eeb75912604055f Mon Sep 17 00:00:00 2001 From: Davide Di Ruscio Date: Mon, 12 Jan 2026 19:42:58 +0100 Subject: [PATCH] [logseq-plugin-git:commit] 2026-01-12T18:42:58.019Z --- .../EditoringChairing___SOSYM-25-00005370.md | 69 ++++++++++++++++++- 1 file changed, 68 insertions(+), 1 deletion(-) diff --git a/pages/EditoringChairing___SOSYM-25-00005370.md b/pages/EditoringChairing___SOSYM-25-00005370.md index 3e69bd8f..ea2d43d0 100644 --- a/pages/EditoringChairing___SOSYM-25-00005370.md +++ b/pages/EditoringChairing___SOSYM-25-00005370.md @@ -25,7 +25,74 @@ todoist:: https://app.todoist.com/app/task/software-and-systems-modeling-manuscr - I could not find the paper [25]. I could not find any paper with that title ("Formal concept analysis for dynamic resource reconfiguration in energy-efficient cloud computing") in Google Scholar, the DOI link does not work, and the relevant volume and issue of the journal do not list any papers with "Formal" in the title: https://www-computer-org.libproxy.york.ac.uk/csdl/journal/cc/2023/02. These incorrect references (or references to missing papers) are representative of the hallucinations caused by improper use of generative AI. I suggest the editor to thoroughly check the other references in the paper and make a decision on this aspect. - - + - Publilc comment + - In this article, the authors propose using Formal Concept Analysis to describe the interdependencies between tenants and application instances, and present an algorithm for consolidating tenants into a reduced set of application instances and servers, with the aim to reduce the number of active servers and therefore save energy. The authors show a comparison of their approach against other algorithms, running within the CloudSim Plus environment. The authors show results that compare positively against those of the other algorithms, and set a number of future research directions, including validation on real testbeds and extension to heterogeneous environments (as the simulation used homogeneous servers). + + While I appreciate the value of reducing the number of servers required to host a number of tenants, I feel that this paper is not a good match to SoSyM. The modelling in this paper seems to be limited to enumerating the servers, VMs, applications, and tenants, and setting the incidence matrix that relates tenants to applications. An enumeration of tenant-application dependencies is not a good example of the rich type of modelling (e.g. architectural / behavioural modelling) that I would normally associate with SoSyM papers. There is a subconcept-superconcept relationship implicit in FCA, but as far as I can tell this is automatically derived from the incidence matrix, so the contribution would be much more appropriate to a cloud computing journal (indeed, some of the cited works, like [40, 41], are from such journals), or to an operations research journal (given this is essentially a constrained resource allocation problem). + + In addition, it appears the algorithm itself is based on a multi-stage greedy search, which I would normally consider to be weak to local decision-making. In Section 5.2, the authors claim that "The algorithm's dual-phase approach ensures both optimal initial resource allocation and continuous optimization", which is a very strong claim. However, unless I have misunderstood Algorithms 2 and 3, I can think of one trivial counter-example that would show the algorithms cannot guarantee optimal results, as it is claimed. Consider this scenario: + - We have three servers: s1 has capacity=30, s2 has capacity=20, and s3 has capacity=20. + - Each server has a VM which takes up their entire capacity (for simplicity): v1 in s1, v2 in s2, and v3 in s3. + - Each VM has an application instance: a1 in v1, a2 in v2, a3 in v3. + - We have 3 tenants as well: they can be hosted in any of the three application instances, and delta(a, t) = 10 for every a in A and t in T. + + My understanding is that Algorithms 2 and 3 would work together as follows: + - Algorithm 2 will first add t1 to s2, as it's the first server with the minimal stimulus of 20. + - Algorithm 2 will then add t2 to s2, as it has the minimal stimulus of 10. + - Algorithm 2 will then add t3 to s3, as it has the minimal stimulus of 20 among the servers that can still host it. + - Algorithm 3 will power off s1 as it has the maximum stimulus and is not hosting any tenants. + + We have now ended up with 2 servers with a total capacity of 40 and a total unused capacity of 10, when optimally we could have just moved all tenants to the larger server with a capacity of 30. I acknowledge this is still an improvement over the original 3 servers, but it is not the optimal solution, so the authors cannot claim it "ensures [...] optimal initial resource allocation". + + Incidentally, the algorithm itself is *not* energy-aware. It aims to save energy, but it does not use any kind of energy-related information as far as I could tell. It is strictly grouping based on resource usage, and Section 4.2 explains the resources are CPU, memory, and I/O. This impacts the title as well, as it claims the approach is energy-aware. + + The above concern is a matter of ensuring the claims are adjusted to represent more faithfully the capabilities and limitations of the algorithm: the results in Section 6 would in principle support the argument that the algorithm is a valuable contribution. However, the study itself has problems: + - To start with, I could not find any link to a research artefact that would allow for independent verification of the results. + - The paper appears to assume that the reader is deeply familiar with the nature of the simulation implemented by the CloudSim Plus tool. However, as I mentioned above, SoSyM is not a cloud computing journal, and the audience will not be familiar with this tool (in fact, I have never heard of nor used this simulation tool). + - The paper mentions the impact of the algorithm on simulated metrics such as energy consumption (Fig 9), SLA violations (Fig 15), energy savings (Table 9), and network latencies (Fig 17), without explaining how these are simulated by CloudSim. + - Section 6.3.4 says that " FCA ability to identify optimal tenant groupings [...], making it particularly suitable for dynamic cloud environments", but it is unclear how this dynamism is reflected in the CloudSim simulation. Do tenants, applications, and/or their relationships change over time in the evaluated simulation? It is unclear how the authors have validated this particular claim. + - Section 6.3.5 mentions three scenarios for sensitivity analysis based on demand variability, but it does not explain how this variability is quantified or implemented in the simulation. The metrics appear to be from single runs with 1000 tenants of each algorithm, which would not be appropriate for a sensitivity analysis due to the stochasticity of the simulation: Section 6.1 for example mentions that "each tenant requests a resource vector with values randomly generated between 100 and 500 units", so the results could potentially vary significantly from one run of the simulation to the other. I would have expected to see confidence intervals instead of individual values for each metric, based on not one run per algorithm, but rather a number of executions for each algorithm that would ensure the confidence intervals would be representative. + - Incidentally, 6.1 mentions a "data center comprising 110 homogeneous servers", but only "10 application instances". How can there be fewer application instances than servers? Do the authors mean that each server has 10 application instances? How was the FCA tenant-application incidence relationship generated in these CloudSim simulations? + + I also note that this algorithm appears to be strictly limited to server consolidation, i.e. shutting down servers and migrating tenants to other servers - it cannot, for example, start a slightly larger server to reassign multiple tenants into it. It is also dependent on the definition of that incidence relationship, and it does not clearly explain how that relationship would be defined in a real-world environment. Who would know about all the application instances where every tenant can be hosted, and how would they maintain this information over time? + + Finally, the presentation of the algorithm needs a near complete overhaul, far beyond what would be appropriate for a revision: + - First, while Section 4.2 talks about virtual machines, the algorithms do not use these virtual machines at all - they only work with servers, application instances, and tenants. The concept of VM could be removed altogether without impacting the algorithms at all - this seems like a severe oversight. + - Section 5.1 makes some additional definitions (load of capacity server, capacity of physical server) that should be done instead in Section 4.2 (as the size and capacity of the server), and repeats some definitions (like delta(a, t)) that are already made in Section 4.2. + - Section 4.2 defines reg(t) as a d-dimensional vector without having defined d first. Please reorder the definitions. + - I understand that v_0 and a_0 are meant to be d-dimensional vectors. Please clarify. + - State(s) should be renamed to Active(s) as it is strictly a Boolean predicate, rather than returning one of a larger set of states. + - In (1), S_i is not defined anywhere. + - In (2), the definition should have reused a(t), e.g. by saying "if a(t)=a_i". (3) should have been formalised similarly. + - (4) appears to contradict a(t). a(t) indicates there is exactly one application instance hosting the tenant t, but (4) says that they must be assigned to *at least* one. + - (5) mismatches the sentence above it. The sentence above it should say that "Each virtual machine must contain AT MOST a single copy of a given application instance". + - Section 5 starts with the ACT and APT algorithm, but APT depends on the concept lattice having been set up first. Please rearrange the discussion to start with the concept lattice setup (Section 5.3), and then discuss the algorithms that use the lattice. + - The Figure 2 flowchart does not clearly relate to the various algorithms, and could be much better explained via an algorithm rather than as a flowchart. It also has overlapping and crossing lines, and the notation does not follow any known standard (which is important to the SoSyM audience). + - It is unclear whether a single round of consolidation (a single execution of Algorithm 3) is performed, or if several rounds are performed (e.g. until no further migrations are done). Please clarify. + - The discussion of the algorithm mentions both ADD_NEW_TENANT (Algorithm 1), and ADD_TENANT_TO_SERVER (Table 2). Please unify. + - Algorithm 4 suggests that execution stops on the very first super-concept where at least one tenant could be placed (the "break" on line 22). This contradicts the discussion in the paper. Please correct. + - In Section 5.3, the summation of weights in the CM(CD) definition does not make sense. Suppose we have only three tenants (t1, t2, and t3), and only two concepts, one whose intention is {t1, t2}, and one whose intention is {t2, t3}. The first concept would have weight 2/3, the second concept would have weight 2/3. Adding them together would be 4/3, and not 1, but they would have CM(C) = 1. In fact, CM(CD) appears entirely superfluous and CM(C) should be enough. + - The 3D visualisation in Figure 4 does not provide any value to the reader. It is incorrect to show values other than 0 and 1, as the incidence matrix is strictly binary in nature (either a tenant and an application instance are related, or not). + - Figure 5 is more representative of the nature of the relationship, but it is not possible for the reader to follow the rearrangement of the applications and tenants. Please relabel the rows and columns in b) appropriately to clearly show how the applications and tenants in a) were rearranged to produce the shown clusters. For example, in Fig 5a T1 is related to A1, A2, A6, and A7, but in Fig 5b T1 is related to A1 to A4 - I would instead expect the first rows of Fig 5b to be A1, A2, A6, and A7. The caption says as much: "Reordered matrix". + - Please explain to the SoSyM readers what is a "Galois correspondence" in Section 5.3.3. + - In Figure 7, please clearly explain what you mean with "Relation" (is it the subconcept relation?), and who exactly (and how) selected C3, C6, and C4. I also note that if the arrows are meant to be subconcept relations, then the diagram is incorrect: C7 is not a subconcept of C5 as neither the tenants of C7 are not a subset of the tenants of C5, nor the apps of C5 are a subset of the apps of C7. + - Section 5.4 is simply incomplete, being made up of just 3 lines and not showing any actual evaluation parameters. + + To conclude my review: the paper is not a good fit for SoSyM, the study is lacking a discussion of the underlying simulation and a link to a verifiable research artefact, the title of the paper and its claims need to be adjusted to reflect the strengths and weaknesses of the algorithm more accurately, and the formalisation of the algorithm is inconsistent and is in need of major improvement. I have also noticed a number of concerning issues about the bibliographic references, which I list below, as well as a number of minor presentational problems. For all these reasons, I think that the paper needs more work before it can be published than what would be appropriate for a revision. + + Here are my presentational and bibliographic comments: + - There are typos in the text (e.g. "reacll" in Section 5.1), and broken references to figures and algorithms (Figure ?? and Algorithm ??). + - Where Section 2.2 introduces the concept of FCA and says that Rudolf Wille introduced it in 1982, it should cite the original paper proposing this idea. + - Figure 1 is poorly explained. Who is the "consumer" and who is the "producer"? Why are IaaS, PaaS, and SaaS stacked vertically like that? Which of these models is relevant to the paper, and how do "tenant" and "application instance" map to those models? + - In Section 5.1, remove "sophisticated" from "sophisticated migration strategy". It is up to the reader to judge whether your strategy is sophisticated or not. Please limit the discussion to a factual description of your algorithm. + - Section 5.1 ends abruptly, followed by a Section 5.2 header that does not contribute anything. Remove the Section 5.2 header to allow the discussion to flow into the itemised list, and reorganise the floating elements (Algorithm 2 to Algorithm 4, Figure 2, Table 2) so they do not disrupt the conversation. + - In Section 6.2.1, the authors say that "We implemented a Q-learning-based scheduler [47]", but [47] appears to be from a different set of authors. Did the authors mean to say that they implemented the Q-learning-based scheduler described in [47]? + - The bibliographic references need to be thoroughly checked. I selected [21-25] as a sample, and found issues in all of them: + - The DOI link for [21] points to a different ICWS 2010 paper ("Formal Specification and Verification of Data-Centric Service Composition"). Please correct your link. + - I could not find the paper [22]. I could not find any paper with that title in Google Scholar at all, and volume 2, issue 1 of the Journal of Cloud Computing does not mention it either: https://link.springer.com/journal/13677/volumes-and-issues/2-1. + - The DOI link for [23] does not work (https://doi.org/10.1109/ICSS.2013.6550432). The correct DOI is 10.1109/ICSS.2013.13. + - The DOI link for [24] points to a different CLOUD 2012 paper. I could not find a paper with this title in Google Scholar (""An approach for tenant placement in multi-tenant saas applications"). I could not find this paper among the CLOUD 2012 papers, either. + - I could not find the paper [25]. I could not find any paper with that title ("Formal concept analysis for dynamic resource reconfiguration in energy-efficient cloud computing") in Google Scholar, the DOI link does not work, and the relevant volume and issue of the journal do not list any papers with "Formal" in the title: https://www-computer-org.libproxy.york.ac.uk/csdl/journal/cc/2023/02. - Reviewer 2 / REJECT - Reviewer 3 / REJECT - The paper proposes a model-driven approach to address energy inefficiencies in multi-tenant cloud data centers caused by resource fragmentation and inter-tenant interference. The authors introduce a methodology using Formal Concept Analysis (FCA) to systematically identify semantic dependencies between tenants based on shared application usage, constructing a concept lattice to guide tenant grouping. Two core algorithms, the Algorithm for Placement of Tenants (APT) and the Algorithm for Consolidation of Tenants (ACT), are developed to leverage this lattice for optimizing resource utilization and minimizing network traffic. The approach is evaluated via simulation using CloudSim Plus, with results reporting significant reductions in active servers and energy consumption compared to baselines such as Best-Fit Decreasing and Genetic Algorithms.