{"id":"c300bab2-e170-4080-9ab8-ebf8d7cf00f6","arxiv_id":"2505.00299","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":2.0,"correctness_risk":"high","formal_verification":"none","parameter_count":3,"one_line_summary":"Applying standard A3C reinforcement learning to microservice scheduling is claimed to reduce task delay and improve success rate, but no reproducible evidence is provided.","lead":"A team applies the A3C reinforcement learning algorithm to schedule microservice tasks in data centers, reporting lower delays and higher success rates than several baselines. A generalist might read it as an example of standard AI techniques applied to infrastructure management, but the paper lacks the data and code needed to check the results.","discovery_kind":"incremental","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The central empirical claim is untestable: the experimental pipeline—state encoding, reward coefficients, action mapping, and baselines—is unspecified, and Table 1 reports single numbers without variance.","rationale":"The reader's weakest assumption already identifies the same load-bearing concern: the experimental setup is underspecified, so the reported empirical advantage of A3C cannot be evaluated. I agree with that assessment. The paper applies a textbook A3C algorithm to a generic MDP formulation, so its contribution has to rest on the experimental results. Those results are presented as single numbers from an undocumented pipeline. There is no released code, no data artifact, no reward coefficients, no hyperparameter list, and no repeated-run statistics. The baseline citation for 'static polling strategy[26]' points to a survey rather than an implemented method, which further undermines confidence that a fair comparison was performed. The A3C equations themselves are standard and not internally inconsistent; the problem is evidentiary, not mathematical. A legitimate revision would need to provide the environment and rerun the comparison with variance reporting. Since the reader's verdict is already REJECT with moderate confidence and high correctness risk, my independent read does not change that verdict. The proposed concrete test—releasing the complete pipeline and reproducing Table 1—would directly settle whether the reported superiority holds or whether the claim is an artifact of unspecified choices.","tokens_in":6983,"tokens_out":2392,"duration_ms":26883,"concrete_test":"Ask the authors to release the complete simulation environment—code, reward function coefficients, state and action definitions, preprocessing scripts, and hyperparameter settings—and independently rerun the Table 1 comparison across at least five random seeds. If the released runs do not reproduce A3C's 88.2% success rate and 78.6 ms delay with confidence intervals that do not overlap the DQN baseline, the central empirical claim fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that A3C achieves an 88.2% scheduling success rate, 78.6 ms average task delay, and 732 s convergence time (Table 1). For this claim to be meaningful, the comparison must be well-defined and reproducible. Section III.A provides only a vague description: missing entries are cleaned, units are standardized, and request sequences are segmented into time windows. It never states the state features, reward function coefficients, action space mapping, number of services or nodes, episode length, or any hyperparameters. The baseline 'static polling strategy[26]' cites a survey on microservice architecture rather than a concrete scheduling algorithm, so the reader cannot determine what was actually implemented. The table reports point estimates only, with no variance, error bars, or significance tests, so the 6.5-point success-rate gap over DQN could be an artifact of preprocessing choices or random seed. This is not a theoretical flaw in A3C itself; the equations in Section II are standard actor-critic. The load-bearing weakness is empirical: the reported superiority cannot be checked, reproduced, or falsified from the information given.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper applies the Asynchronous Advantage Actor-Critic (A3C) reinforcement learning algorithm to microservice resource scheduling. It models the scheduling problem as a Markov decision process, trains policy and value networks asynchronously, and evaluates the method on the Google Cluster Trace against static polling, priority-based scheduling, Q-learning, and DQN baselines. The central empirical claim, stated in Section III.B and Table 1, is that the proposed A3C scheduler achieves an 88.2% scheduling success rate, 78.6 ms average task delay, and 732 s convergence time, outperforming all baselines. The MDP and policy-gradient equations in Section II are standard actor-critic formulas; the experimental evidence is presented entirely through Table 1 and Figures 2 and 3.","tokens_in":7102,"tokens_out":5310,"duration_ms":55963,"significance":"If the empirical claim were supported, the paper would provide a practically useful demonstration that a standard RL algorithm can improve microservice scheduling on a real cluster trace. The paper correctly states the standard A3C advantage-function and n-step TD loss equations, and the choice of a public dataset is appropriate. However, the scientific value rests entirely on the comparability and reproducibility of the experiment, and that is not established: no code, hyperparameters, reward coefficients, state encoding, action mapping, number of runs, or statistical variation are reported. The claimed improvements cannot be checked or falsified from the information given, so the paper in its current form contributes an application narrative rather than a validated empirical result.","major_comments":[{"comment":"The MDP formulation is never instantiated. The state, action, and reward are written symbolically, but the paper does not specify which Google Cluster Trace fields become state features, how the service dependency topology is encoded, whether the action space is discrete or continuous, how actions map to resource allocations, or the coefficients of the composite reward over delay, utilization, and completion rate. Without these definitions, the equations in Section II cannot be evaluated and Table 1 cannot be reproduced. This is the load-bearing gap because the paper's only evidence for the proposed method is the reported improvement over baselines.","section":"Section II and Section III.A"},{"comment":"The comparison reports single point estimates for average task delay, scheduling success rate, and convergence time, with no error bars, confidence intervals, number of independent runs, or significance tests. The claimed 6.5 percentage-point success-rate advantage over DQN and the 12.6 ms delay reduction could be within run-to-run noise. Convergence time is also undefined: the paper does not state the convergence criterion, the number of training epochs, the hardware used, or why the non-learning baselines are marked with a dash.","section":"Table 1 and Section III.B"},{"comment":"The text asserts rapid early convergence and stable resource utilization under concurrent load, but Figure 2 has no axis labels or numerical scale, and Figure 3 reports no quantitative metric such as utilization variance or load imbalance. The claims of 'balanced resource utilization' and 'more stable scheduling behavior' are therefore not verifiable from the presented material.","section":"Section III.B, Figures 2 and 3"},{"comment":"The baseline implementations are not identifiable. Table 1's 'Static polling strategy[26]' cites a general survey on microservice architecture, not a concrete polling algorithm, and 'DQN Scheduling Strategy[29]' actually refers to a D3QN-based method, not DQN. In addition, the citations in Section II appear mismatched: 'Zhan [14]' points to a federated-learning paper, while the federated-learning statement is attached to [15], which is Zhan's spatiotemporal-feature paper. These issues compound the reproducibility problem because the reader cannot determine what was actually compared.","section":"References and baseline implementations"}],"minor_comments":[{"comment":"The mathematical notation is garbled in places, for example '},...,,{ 21 nsssS' and '},...,,{ 21 maaaA'; these should be properly typeset as set definitions.","section":"Section II"},{"comment":"The author block includes an unattributed name 'Tengda Tang' and a duplicated affiliation entry for the University of Michigan; these are likely metadata errors and should be corrected.","section":"Author metadata"},{"comment":"The text refers to 'the first 50 epochs' in Figure 2, but Table 1 reports convergence time in seconds; the relationship between epochs and wall-clock convergence time is never clarified.","section":"Section III.B"},{"comment":"Several references, including [5]-[12] and [16]-[22], are unrelated to microservice resource scheduling and do not support the surrounding claims; either connect them explicitly to the argument or remove them.","section":"Introduction and Section II"},{"comment":"The phrase 'A3C algorithm proposed in this study' overstates novelty; since A3C is an existing published algorithm, the contribution should be described as an application or adaptation unless a novel variant is actually introduced.","section":"Conclusion"}],"recommendation":"reject","confidential_remarks":"I would flag for editorial scrutiny that several references are authored by one of the paper's co-authors (S. Duan appears in [9] and [17]) and are unrelated to the scheduling content, and that many introductory references appear to be citation-stack padding. This does not change the technical verdict, but it is a separate integrity concern. The paper's central empirical claim is untestable as written, so I do not see a path to acceptance without a substantially new experimental section that specifies the environment, reward, state encoding, hyperparameters, and statistical methodology."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know this before reading: the paper is a routine application of textbook A3C to a generic microservice-scheduling MDP. The only thing that could make it interesting—the empirical claim—cannot be evaluated because the experimental pipeline is almost completely unspecified.\n\nWhat the paper does well: it identifies a real problem (dynamic resource scheduling in microservices), uses the Google Cluster Trace, a legitimate real-world dataset, and compares against sensible baselines (static polling, priority-based, Q-learning, DQN). The A3C equations in Section II are standard and correctly stated. If the numbers in Table 1 were trustworthy, the result would be a modest, useful data point in the RL-for-scheduling literature.\n\nThe soft spot is load-bearing: the experiments are not reproducible. Section III.A says missing entries are cleaned and time windows are segmented, but never states the state features, reward coefficients, action mappings, number of services/nodes, episode length, or any hyperparameters. Table 1 reports single point estimates with no error bars, no number of runs, and no significance tests. The \"static polling strategy[26]\" cites a survey on microservice architecture, not a concrete algorithm, so the reader cannot tell what was actually implemented. The convergence-time claims (732s vs 978s) are meaningless without the hardware and environment details.\n\nThe citation pattern is also a concern. Several references are unrelated to scheduling (vision, HCI, NLP) and appear to be padding, and two in-text citations are swapped relative to the reference list (Zhan [14] vs [15]). Reference [9] and [17] are by one of the paper's co-authors (S. Duan) but are irrelevant to the scheduling result. This is minor in itself but adds to the impression of a hastily assembled manuscript.\n\nThere is no deep theoretical flaw here—the math is correct but it does not carry the empirical load. The paper's central claim—that A3C achieves 88.2% success and 78.6ms delay—is simply untestable from the information given. I would not bring this to reading group or cite it. A serious editor should desk reject it; it does not yet deserve referee time. If the authors release code, specify the full environment, and report variance across multiple seeds, a resubmission could be a reasonable workshop-level paper.","headline":"Standard A3C applied to microservice scheduling with a promising setup but an entirely untestable empirical section; desk reject unless the authors supply full experimental details.","tokens_in":7723,"tokens_out":1911,"would_cite":false,"duration_ms":21129,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that an A3C reinforcement-learning scheduler outperforms static polling, priority-based, Q-learning, and DQN baselines for microservice resource allocation, cutting average task delay to 78.6 ms and raising scheduling…","keywords":["microservice architecture","resource scheduling","reinforcement learning","A3C","Asynchronous Advantage Actor-Critic","Markov decision process","Google Cluster Trace","task scheduling"],"falsifier":"Reproduce the experiment on the same 29-day Google Cluster Trace with the reward function, state encoding, and action mapping fixed as described, and check whether A3C still beats DQN on all three metrics; if A3C's success rate falls to or below 81.7%, its delay rises to or above 91.2 ms, or its convergence time exceeds 978 seconds under comparable tuning, the central empirical claim collapses.","tokens_in":6694,"feed_emoji":"⚙️","tokens_out":5543,"duration_ms":51401,"temperature":0.7,"pith_summary":"The paper argues that asynchronous advantage actor-critic (A3C) reinforcement learning provides a better way to schedule microservice tasks than static rules or earlier reinforcement-learning methods. It models scheduling as a Markov decision process whose state captures resource usage, request load, and service dependency topology, and trains multiple agents in parallel to allocate resources. On a scenario built from Google Cluster Trace data, the method reports an average task delay of 78.6 ms, an 88.2% scheduling success rate, and convergence in 732 seconds, beating Q-learning and DQN on all three metrics. A sympathetic reader would care because the result suggests a standard reinforcement-learning algorithm can adapt to fluctuating cloud workloads without hand-crafted heuristics.","feed_headline":"A3C scheduling beats DQN, Q-learning, and static rules","feed_subtitle":"On a cluster-trace scenario, the RL method cuts average task delay to 78.6 ms and converges in 732 seconds.","key_machinery":"The central mechanism is the Asynchronous Advantage Actor-Critic (A3C) training loop, augmented with an n-step temporal-difference target for the critic and parallel worker threads sharing a global parameter server. The actor outputs a stochastic policy $\\pi(a|s;\\theta)$; the critic estimates the state value $V(s;\\theta_v)$; and the advantage function $A(s_t,a_t)=R_{t+1}+\\gamma V(s_{t+1})-V(s_t)$ is used to reduce policy-gradient variance. The state space $S=\\{s_1,\\dots,s_n\\}$ bundles resource consumption, dynamic request load, and service dependency topology, while the action space $A=\\{a_1,\\dots,a_m\\}$ is the set of resource allocation decisions, and the scheduler maximizes $\\mathbb{E}\\sum_t \\gamma^t R(s_t,a_t)$. What carries the argument is the claim that asynchronous multi-threaded updates make this optimization converge in 732 seconds while keeping delay and success rate competitive.","core_discovery":"The central discovery claimed is empirical: an A3C-based scheduler, trained with asynchronous parallel workers and an actor-critic advantage update, is faster and more reliable than existing baselines in a microservice scheduling environment constructed from Google Cluster Trace. The proposed method attains an 88.2% scheduling success rate, an average task delay of 78.6 ms, and a convergence time of 732 seconds; the strongest baseline, DQN, reaches 81.7% success, 91.2 ms delay, and 978 seconds. The paper presents this as evidence that separating policy and value networks and updating them asynchronously yields a scheduling policy that adapts to dynamic load while keeping resource allocation stable under concurrency.","pith_inferences":["A testable extension would be to hold the network architecture fixed and compare A3C against a synchronous actor-critic; if convergence time remains around 732 seconds, the advantage is not due to asynchrony alone.","Because the reward function is never spelled out, the published margins could plausibly shrink or reverse under different operator priorities; a deployment study should report the exact reward coefficients before treating 88.2% as robust.","Since the state includes service dependency topology only as part of a generic state vector, a graph neural network policy that explicitly reasons over the dependency graph is a natural next test.","The Table 1 comparison does not report variance across random seeds; re-running the experiment with multiple seeds would reveal whether the success-rate gap over DQN is stable or within noise."],"forward_implications":["If the reported results hold, microservice schedulers can replace hand-tuned priority and round-robin policies with a trained A3C policy that reacts to load changes in real time.","The 978-to-732 second convergence improvement over DQN suggests that asynchronous parallel sampling is a practical way to reduce training time for scheduling agents.","The 88.2% success rate against 81.7% for DQN implies that even a modest policy-gradient advantage translates into meaningfully fewer failed task placements under high concurrency.","The method's reported stability under concurrent load would make it a candidate for peak-load and fault-recovery scheduling scenarios where static rules degrade."],"supporting_citations":[{"why":"Supplies the 29-day Google Cluster Trace dataset used to construct the scheduling scenario.","marker":"[23]"},{"why":"Supports the use of the trace as a realistic simulation platform by describing its statistical characteristics.","marker":"[25]"},{"why":"Provides the static polling strategy baseline that the proposed method is compared against.","marker":"[26]"},{"why":"Provides the priority-based scheduling strategy baseline for the comparison.","marker":"[27]"},{"why":"Provides the Q-learning baseline that the proposed method must beat on delay and success rate.","marker":"[28]"},{"why":"Provides the DQN baseline, the strongest competitor in the comparison, which the proposed method outperforms.","marker":"[29]"}],"fun_headline_variants":["A3C RL scheduler cuts microservice delays to 78.6 ms","Microservice scheduling: A3C beats DQN by 6.5% success","Asynchronous A3C scheduling improves convergence to 732s","RL scheduler: A3C outperforms DQN in task delay and success","A3C-based scheduling achieves 88.2% success rate in tests"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the unstated choices in turning Google Cluster Trace into a scheduling Markov decision process—the reward coefficients, the state encoding, and the action-to-resource mapping—are faithful and unbiased; if those choices differ, the reported delay, success rate, and convergence time could change materially.","fun_headline_variants_meta":{"raw":{"variants":["A3C RL scheduler cuts microservice delays to 78.6 ms","Microservice scheduling: A3C beats DQN by 6.5% success","Asynchronous A3C scheduling improves convergence to 732s","RL scheduler: A3C outperforms DQN in task delay and success","A3C-based scheduling achieves 88.2% success rate in tests"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000246,"raw_usage":{"total_tokens":1502,"prompt_tokens":869,"completion_tokens":633,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":485,"completion_tokens_details":{"reasoning_tokens":531}},"tokens_in":485,"tokens_out":633,"duration_ms":5697,"temperature":1.0,"reasoning_tokens":531,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T04:46:05.384009+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Reproduce the experiment on the same 29-day Google Cluster Trace with the reward function, state encoding, and action mapping fixed as described, and check whether A3C still beats DQN on all three metrics; if A3C's success rate falls to or below 81.7%, its delay rises to or above 91.2 ms, or its convergence time exceeds 978 seconds under comparable tuning, the central empirical claim collapses.","supporting_citations":[{"cited_title":"Literature survey: statistical characteristics of Google cluster trace","cited_arxiv_id":null,"evidence_quote":"Supports the use of the trace as a realistic simulation platform by describing its statistical characteristics."},{"cited_title":"Analysis and clustering of workload in Google cluster trace based on resource usage","cited_arxiv_id":null,"evidence_quote":"Supplies the 29-day Google Cluster Trace dataset used to construct the scheduling scenario."},{"cited_title":"A survey on microservices architecture: Principles, patterns and migration challenges","cited_arxiv_id":null,"evidence_quote":"Provides the static polling strategy baseline that the proposed method is compared against."},{"cited_title":"Optimizing Cloud Performance: A Microservice Scheduling Strategy for Enhanced Fault- Tolerance, Reduced Network Traffic, and Lower Latency","cited_arxiv_id":null,"evidence_quote":"Provides the priority-based scheduling strategy baseline for the comparison."},{"cited_title":"DoME: Dew computing based microservice execution in mobile edge using Q-learning","cited_arxiv_id":null,"evidence_quote":"Provides the Q-learning baseline that the proposed method must beat on delay and success rate."},{"cited_title":"D3QN-based secure scheduling of microservice workflows in cloud environments","cited_arxiv_id":null,"evidence_quote":"Provides the DQN baseline, the strongest competitor in the comparison, which the proposed method outperforms."}],"review_version":1}