{"id":"91b2eb20-efba-4e41-bd79-aea84ba5daf2","arxiv_id":"2508.05821","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A score-based dynamic load balancer that picks the VM with the most available resources outperforms the throttled strategy in CloudSim, cutting response time by 34-37% and 24-hour cost by 15%.","lead":"This paper proposes a Score-Based Dynamic Load Balancer that sends each cloud task to the virtual machine with the most free CPU, RAM, and bandwidth, while capping how many tasks each VM can hold. In CloudSim simulations it reports 34-37% lower response times and 15% lower 24-hour cost than the throttled load balancer.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"SBDLB's edge may come from an unfair baseline (throttled = 1 task/VM vs threshold-3 concurrency), not from the score.","rationale":"The reader identified the threshold as overfit to the test workloads; I agree that is a real risk. However, the more load-bearing problem is that the throttled baseline does not use any equivalent threshold, so the experiment conflates the scoring rule with a concurrency allowance. Even a well-generalizing threshold would produce a large advantage over a baseline that is artificially limited to one task per VM. The paper's own description of throttled as distributing tasks 'sequentially across VMs' supports this reading, and CloudSim's standard ThrottledLoadBalancer marks a VM unavailable while it has an allocated cloudlet. Because SBDLB's threshold of 3 was tuned on the same 100K-500K workloads (Sec. IV.C, Fig. 3), the headline numbers could be a tuning artifact plus an unfair baseline, not evidence for the score. This does not prove the method is bad, but it shifts the burden: the authors must show the score itself matters, for example by comparing against a throttled variant with the same threshold, and release the simulation code or parameter files so the claim is checkable. The statistical p-values do not address this confound. Therefore the paper should not be accepted as-is; it needs a matched-baseline experiment and reproducibility artifacts. This keeps the verdict conditional rather than reject, because the concern is concrete and testable and the method may still have value once the baseline is made fair.","tokens_in":9357,"tokens_out":5176,"duration_ms":61758,"concrete_test":"Modify the throttled baseline to use the same per-VM task threshold/concurrency limit as SBDLB (or, equivalently, set SBDLB's threshold to 1 to match throttled) and rerun Scenarios 1 (Sec. VI.A) and 2 (Sec. VI.B) on the same workloads. If the 34%/37% response-time and 13% processing-time advantages shrink to noise, the claimed advantage is an artifact of threshold/concurrency allowance rather than the score; if they persist, the scoring rule contributes independently. Report at least 10 independent seeds with confidence intervals.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The load-bearing weakness is that the SBDLB-vs-throttled comparison does not isolate the score. SBDLB bundles two changes: (i) a per-VM task threshold of 3 (Sec. IV.C), and (ii) a resource-availability score. CloudSim's throttled strategy—which the paper itself describes as distributing tasks \"sequentially across VMs\" (Sec. IV.D)—allocates at most one active task per VM in the standard implementation. Thus the baseline is concurrency-limited to 1, while SBDLB is concurrency-limited to 3, with that limit tuned on the same workloads used for evaluation. The reported 34%/37% response-time reductions and 13% processing-time reductions could therefore be driven by allowing more concurrent tasks per VM (and by tuning that allowance), not by the scoring rule. This is an internally unfair comparison, not merely a generalization risk. The p-values in Sec. VI.A/VI.B only test the two bundled implementations; they cannot separate the score's contribution from the concurrency-limit difference. Without code or a baseline-matched variant, the central claim that \"SBDLB outperforms throttled\" is unverified.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a Score-Based Dynamic Load Balancer (SBDLB) that selects a virtual machine for each incoming task based on a score computed from available MIPS, RAM, and bandwidth, after filtering out VMs that exceed a task threshold of 3. The authors simulate a social-media-like workload (Reels, Images, Text) in CloudSim 7G with heterogeneous physical machines and VMs, and compare SBDLB against the throttled load balancing strategy in four scenarios: VM scalability, varying number of data centers, task allocation across high-/low-spec VMs, and a 24-hour load profile. They report that SBDLB reduces average response time by 34% and 37% in the two principal scenarios, reduces data center processing time by 13%, and lowers 24-hour operating cost by 15%, with p-values reported for the main comparisons.","tokens_in":9605,"tokens_out":5822,"duration_ms":58622,"significance":"If the comparison were clean, the contribution would be a simple, interpretable, dynamic load-balancing heuristic with clear energy/cost co-benefits. The manuscript is unusually explicit about its simulation setup and uses realistic workload proportions, which is commendable. However, the paper does not release code and the evaluation currently bundles a concurrency-threshold change with the scoring rule, so the headline improvements are not attributable to the proposed score. The experimental protocol also lacks replication details. The idea is promising and the issues are fixable with additional controlled experiments, but the central claim is not yet established.","major_comments":[{"comment":"The comparison does not isolate the scoring rule. §IV.D describes the throttled baseline as distributing tasks \"sequentially across VMs,\" i.e., at most one active task per VM in the standard CloudSim implementation, while §IV.C sets a VM task threshold of 3 for SBDLB. The two systems therefore differ in concurrency limit (1 vs 3) as well as in the allocation score; the threshold itself was tuned on the same workload types used in evaluation. The reported 34% and 37% average response-time reductions and the 13% processing-time reduction (Figs. 5a, 6, 8; p-values in §VI.A/VI.B) could be driven largely by allowing three concurrent tasks per VM, not by the scoring rule. Please add controlled variants: throttled with threshold 3, SBDLB with threshold 1, and ideally a threshold-matched baseline, and report these comparisons for all scenarios.","section":"§IV.D and §VI.A–B"},{"comment":"The VM task threshold is selected using \"extensive testing across workloads\" on the same family of workloads (2000 tasks in 250 batches, 1–8 data centers, thresholds 2–4, Fig. 3) that later appear in the evaluation (100K–500K tasks). There is no held-out workload or cross-validation, and the plateau cutoff of 60 VMs in §VI.A comes from the same experimental family. Thus the reported improvements may reflect tuning of the concurrency allowance rather than a general property of the algorithm. Please provide a sensitivity analysis over thresholds (e.g., 1, 2, 3, 4) on held-out workloads and report the final workload results for each threshold.","section":"§IV.C and §VI.A"},{"comment":"The paper states \"only one representative result per scenario\" is shown and no replication counts, standard deviations, or error bars are reported. The p-values (e.g., 3.54e-10, 3.35e-12, 4.48e-9) are not accompanied by the number of independent runs, the statistical test used, or the distribution of the metric; without this, the significance claims are unverifiable. Please include at least 10–30 independent replications per configuration, report mean ± std (or boxplots), and specify the test and multiple-comparison handling.","section":"§VI"},{"comment":"The score is computed as a raw sum \"availableMIPS + availableRAM + availableBW.\" These quantities have different units and scales (MIPS, MB, Mbps), so the sum is dominated by the metric with the largest numeric range and is not a principled resource-availability index. The text also describes normalizing the task length (Eq. 1) to the VM resource range, but does not normalize the resources before summation. Please either normalize each resource component to a common scale (e.g., 0–1) before summing, or justify the linear combination and show the score is not an artifact of unit choice.","section":"§IV.A"}],"minor_comments":[{"comment":"Header contains a typo: \"Analayzed\" should be \"Analyzed.\"","section":"Table IV"},{"comment":"Caption contains \"Accross\" (should be \"Across\"). Also, neither Figure 3 nor Figure 5 clearly labels axes or gives units for response time.","section":"Fig. 5"},{"comment":"The claim that \"preliminary results\" show response time plateaus beyond 80 VMs is not shown; please include or cite the supporting data for this cutoff and for the 60-VM standard.","section":"§VI.A"},{"comment":"The task-allocation comparison (Fig. 9) is qualitative only; provide a quantitative summary, such as the percentage of tasks assigned to high-spec VMs under each policy, and a significance test if possible.","section":"§VI.C"}],"recommendation":"major_revision","confidential_remarks":"I recommend major revision rather than rejection because the main confound can be addressed by adding controlled baselines and sensitivity analyses. Given the current comparison, I would not accept the paper as is. The claimed novelty may be modest; the main value is in the empirical comparison if properly controlled. I would also ask the authors to provide or link to the simulation code to allow verification of the throttled baseline's concurrency behavior."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read this one. It's a straightforward CloudSim load-balancing paper that claims a score-based VM selection rule beats throttled by large margins. The headline numbers are probably overstated because the baseline is not fair: throttled is described as distributing tasks sequentially across VMs, which in CloudSim means one active task per VM, while SBDLB is capped at three active tasks per VM, with that cap empirically tuned on the same workload range used for the final evaluation. So the 34–37% response-time reductions and the 13% processing-time reductions could come mostly from allowing more concurrency per VM, not from the scoring rule itself. The p-values only test the bundled implementations; they cannot separate the score's contribution.\n\nThe paper does have some strengths. The system model is detailed enough to reimplement. The workload generation is realistic: three task types (Reels, Images, Text) with sizes and computational intensities based on cited sources, and a sensible 60/30/10 mix. The authors report p-values for the main comparisons and extend the evaluation to a 24-hour scenario with peak/non-peak variations and a cost analysis. For a modest engineering paper, the presentation is clear and honest about the simulation setup.\n\nThe main weak spot is the confound I described. To make the central claim, the authors need a baseline at the same concurrency limit. For example, compare SBDLB (threshold 3) against a throttled variant that also allows up to three tasks per VM, maybe with simple round-robin in the allowed set, or against a random selection among eligible VMs at threshold 3. Without that, we cannot know whether the score matters at all. There are also smaller issues: no error bars or replication counts, only one representative result per scenario, no released code or parameter files, and energy savings are inferred rather than measured. The novelty is incremental—threshold-based greedy selection has been explored before—but the specific combination is new enough for a niche result.\n\nThis paper is for people who care about CloudSim load-balancing benchmarks. It's a useful case study of how a small implementation choice can confound a comparison, and the workload model is a nice template. I would send it to peer review but with a strong request for a baseline-matched experiment and reproducibility details. As written, the main claim is unverified.","headline":"The SBDLB paper's large gains over throttled are likely confounded by an unfair baseline (concurrency 1 vs 3), so the score's contribution remains unproven.","tokens_in":10075,"tokens_out":7486,"would_cite":false,"duration_ms":58728,"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 Score-Based Dynamic Load Balancer that assigns tasks to the virtual machine with the most spare CPU, RAM, and bandwidth shortens average response times by 34%–37% over throttled load balancing in CloudSim simulations.","keywords":["load balancing","cloud computing","virtual machines","score-based scheduling","CloudSim","response time","energy efficiency","resource utilization"],"falsifier":"Run the same CloudSim 7G comparison with a different arrival pattern—for example, one long burst of tiny tasks followed by silence—and with the task threshold set to 2, 3, and 4. If the throttled strategy matches or beats SBDLB for some threshold/workload combination, the 34% and 37% response-time advantages are a tuning artifact rather than a property of the scoring rule.","tokens_in":9252,"feed_emoji":"☁️","tokens_out":6666,"duration_ms":65320,"temperature":0.7,"pith_summary":"The paper proposes a Score-Based Dynamic Load Balancer (SBDLB) that sends each incoming task to the virtual machine with the most spare CPU, RAM, and bandwidth, after skipping VMs that already hold three tasks. It argues that this real-time scoring rule is a better allocation policy than the widely used throttled load balancer. Using CloudSim 7G simulations modeled on social-media workloads (100K–500K tasks, one to eight data centers, 10–80 VMs per center), the paper reports 34% and 37% lower average response times, 13% lower data-center processing time, and 15% lower 24-hour operating cost for SBDLB. The practical stake is that a simple, state-based rule could make cloud infrastructure more responsive and cheaper to run while using less energy.","feed_headline":"Score-based load balancer beats throttled by 34-37% in CloudSim","feed_subtitle":"Assigning each task to the VM with the most spare CPU, RAM, and bandwidth cuts response time and 24-hour cost.","key_machinery":"The scoring rule: after excluding VMs over a task threshold (set to 3), each remaining VM gets $Score = availableMIPS + availableRAM + availableBW$, and the task goes to the VM with the highest score. Min-max normalization (Equation 1) converts task length into VM resource units, so the score reflects whether a VM has enough spare resources for that specific task. This single real-time score carries the entire allocation decision; no history or prediction is used.","core_discovery":"SBDLB computes a per-VM suitability score as $Score = availableMIPS + availableRAM + availableBW$. A task's length is normalized using min-max scaling so its resource demand is expressed in the same units as each VM's available resources; VMs already holding three tasks are skipped, and a VM that cannot satisfy the normalized demand is assigned a score of $-1$. The VM with the highest score receives the task. In CloudSim 7G comparisons against throttled load balancing across four scenarios—VM scaling, data-center scaling, task allocation, and a 24-hour variation—with 100K–500K tasks, SBDLB achieves 34% and 37% lower average response times in two key tests, 13% lower data-center processing ti","pith_inferences":["Editorial extension: Because SBDLB's score uses only current VM state, the same rule could be dropped into a production broker as a lightweight policy; its main risk would be stale resource readings, not algorithmic complexity.","Editorial extension: The threshold of 3 was tuned on the same workloads used for evaluation, so a fair transfer test would re-tune or adapt the cap per-VM capacity before concluding the gain is intrinsic.","Editorial extension: The reported 15% cost saving follows from shorter processing time in CloudSim's linear cost model; real energy savings would require active data-center power-down, which this simulation does not model.","Editorial extension: Weighting the three resource terms by actual task bottleneck (e.g., CPU-heavy video transcoding) could improve the score further; the paper does not test such weighted variants."],"forward_implications":["At the same task volume, SBDLB keeps response times flat during peak hours where throttled shows spikes, suggesting better handling of daily demand cycles.","Operators can process 500K tasks with three data centers under SBDLB where throttled needs four for a comparable response time, reducing active infrastructure.","Over 24 hours, SBDLB's operating cost is $22,818 versus $26,246 for throttled, a 15% reduction that compounds with energy savings.","Across 100K–500K tasks, SBDLB lowers data-center processing time by 13% on average with reported p-values around $10^{-9}$ to $10^{-12}$, so the gains are consistent across the simulated workloads."],"supporting_citations":[{"why":"CloudSim 7G is the simulation platform on which all comparisons run.","marker":"[25]"},{"why":"The improved throttled algorithm (ITA) is the throttled variant that motivates the comparative baseline.","marker":"[8]"},{"why":"The balanced throttled algorithm is earlier evidence that throttled is a strong baseline, supporting its use here.","marker":"[7]"},{"why":"Meta's data-center locations provide the 24-campus scale that is scaled down to eight data centers in the simulation.","marker":"[28]"},{"why":"The Reels file-size guide provides the 10 MB–1 GB task size for the largest task type.","marker":"[29]"},{"why":"The image-size guide provides the 1–30 MB task size for medium tasks.","marker":"[30]"},{"why":"Visual-content statistics support the 60% Reels / 30% Images / 10% Text task mix.","marker":"[33]"}],"fun_headline_variants":["Score-based load balancer cuts response time 34-37% in CloudSim","Dynamic score-based load balancer reduces cloud costs 15% daily","Real-time VM scoring boosts cloud efficiency and response times","SBDLB improves cloud performance by 34-37% response time","Cloud load balancer with VM scoring cuts processing time 13%"],"cache_read_input_tokens":2816,"weakest_assumption_plain":"The VM task threshold of 3—selected by testing the same 100K–500K task workloads used for evaluation—is assumed to generalize to other load patterns; if it is overfit, the reported gains over throttled could come from tuning rather than from the scoring rule itself.","fun_headline_variants_meta":{"raw":{"variants":["Score-based load balancer cuts response time 34-37% in CloudSim","Dynamic score-based load balancer reduces cloud costs 15% daily","Real-time VM scoring boosts cloud efficiency and response times","SBDLB improves cloud performance by 34-37% response time","Cloud load balancer with VM scoring cuts processing time 13%"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000608,"raw_usage":{"total_tokens":2682,"prompt_tokens":771,"completion_tokens":1911,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":515,"completion_tokens_details":{"reasoning_tokens":1819}},"tokens_in":515,"tokens_out":1911,"duration_ms":14423,"temperature":1.0,"reasoning_tokens":1819,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T23:07:23.758784+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same CloudSim 7G comparison with a different arrival pattern—for example, one long burst of tiny tasks followed by silence—and with the task threshold set to 2, 3, and 4. If the throttled strategy matches or beats SBDLB for some threshold/workload combination, the 34% and 37% response-time advantages are a tuning artifact rather than a property of the scoring rule.","supporting_citations":[{"cited_title":"Cloudsim 7g: An integrated toolkit for modeling and simulation of future generation cloud computing environments,","cited_arxiv_id":null,"evidence_quote":"CloudSim 7G is the simulation platform on which all comparisons run."},{"cited_title":"Ita: The improved throttled algorithm of load balancing on cloud computing,","cited_arxiv_id":null,"evidence_quote":"The improved throttled algorithm (ITA) is the throttled variant that motivates the comparative baseline."},{"cited_title":"A proposed load balancing algorithm over cloud computing (balanced throttled),","cited_arxiv_id":null,"evidence_quote":"The balanced throttled algorithm is earlier evidence that throttled is a strong baseline, supporting its use here."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Meta's data-center locations provide the 24-campus scale that is scaled down to eight data centers in the simulation."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The Reels file-size guide provides the 10 MB–1 GB task size for the largest task type."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The image-size guide provides the 1–30 MB task size for medium tasks."},{"cited_title":"(2018, 6) State of visual content marketing: the statistics","cited_arxiv_id":null,"evidence_quote":"Visual-content statistics support the 60% Reels / 30% Images / 10% Text task mix."}],"review_version":1}