{"id":"7c5a2e0b-40a7-4640-8455-67dc08ebb8ff","arxiv_id":"2507.14597","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"high","formal_verification":"none","parameter_count":6,"one_line_summary":"A GRU forecaster beats CNN, ARIMA, and Prophet on simulated and rescaled load data for edge stream processing, but the transfer-learning and autoscaling stages that complete the proposed framework are not implemented.","lead":"This paper proposes a three-step framework to predict and scale edge data stream processing: a neural network predicts incoming load, transfer learning adapts the model online, and an autoscaling module adjusts operator parallelism. Only the forecasting step is implemented and tested; the other two stages are explicitly described as conceptual.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Central framework claim is unsupported: transfer learning and autoscaling are explicitly conceptual (Section IV), and the only implemented forecaster predicts a single next step (Section V-B), while Section III-A requires forecasts over horizon p; no multi-step or closed-loop evaluation exists.","rationale":"I read the paper in good faith: it is transparent that transfer learning and autoscaling are at a conceptual stage, so the honest contribution is a GRU forecasting benchmark rather than a full framework. The most load-bearing technical assumption is therefore the one-step-to-multi-step transfer, because it is the single measurable link between the implemented experiment and the autoscaling decision required by Section III-A. The base model is explicitly a one-step predictor, yet the scaling rule consumes predictions over the entire horizon p. The checkpoint and restart steps in the Execute phase make forecast lead time critical; if the p-step forecasts degrade, a properly implemented scaler would still act on inaccurate load estimates. The proposed experiment directly measures that gap on the same datasets and model. Given the absence of any multi-step result, any autoscaling evaluation, and any transfer-learning evaluation, the reader's REJECT verdict should stand unchanged.","tokens_in":15629,"tokens_out":4069,"duration_ms":48509,"concrete_test":"Run a multi-step forecasting experiment on the six datasets with the same GRU architecture: for p=5, 10, and 20, generate forecasts over {ϖ̂_i}_{i=n+1}^{n+p} using recursive or direct strategies and report per-horizon SMAPE and RMSE. If the error at the largest p exceeds the one-step SMAPE by more than the time-buffer available from the checkpoint-restart scaling procedure in Section IV-C-1-d, the proactive autoscaling claim fails; if the gap is small, the concern is mitigated, but the transfer-learning and autoscaling modules would still need closed-loop evaluation.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's title and abstract present a complete three-step proactive autoscaling framework, but Section IV states that \"both the transfer learning and autoscaling frameworks are currently at advanced conceptual stages,\" and the conclusion repeats this qualification. The only implemented and evaluated component is the load predictor in Section V, and Section V-B specifies \"a fully connected output layer with a single unit\" used \"to predict the load for the next time step.\" The autoscaling problem formulated in Section III-A, however, requires forecasts over a projection horizon p: f({ϖ_i}_{i=1}^n) ≈ {ϖ̂_i}_{i=n+1}^{n+p}. The scaling decision depends on those future loads, and the checkpoint-restart procedure in Section IV-C-1-d introduces reconfiguration latency that makes lead time essential. No multi-step forecasting experiment, no lead-time analysis, and no runtime evaluation of the transfer-learning or autoscaling modules are reported. Thus the central claim that the framework solves proactive edge stream processing autoscaling cannot be validated; the evidence supports only a narrow one-step forecasting benchmark on constructed datasets.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a three-step framework for proactive horizontal autoscaling of edge stream processing: a GRU-based load forecaster, a transfer-learning module using DTW and MMD/CMMD, and a horizontal autoscaler following the MAPE-K loop. The authors implement and evaluate only the forecasting component, comparing GRU, CNN, ARIMA, and Prophet on six datasets (synthetic IoT traffic and New York City taxi trip records at 1-, 2-, and 5-minute sampling rates). They report that GRU achieves the lowest SMAPE (1.34% on the 5-minute NYCTT set) and lower training time than the baselines. The transfer-learning and autoscaling components are explicitly stated, in Sections IV and VII, to be at the conceptual stage rather than implemented.","tokens_in":15883,"tokens_out":5038,"duration_ms":55797,"significance":"If the forecasting results were conclusive, they would provide a modest contribution to load prediction for distributed stream processing. The paper's broader significance as an autoscaling framework is limited because two of the three components are not implemented or evaluated; the honest disclosure of this limitation is a strength, and the problem formulation in Section III is clear. The forecasting comparison is reproducible in principle, but the evaluation design and the one-step horizon undermine the strength of the claims. The paper does not provide code or machine-checked artifacts, and no falsifiable system-level predictions are tested.","major_comments":[{"comment":"The abstract and title present a complete proactive autoscaling framework, but Section IV states that \"both the transfer learning and autoscaling frameworks are currently at advanced conceptual stages,\" and Section VII repeats this qualification. The experimental evaluation in Section V covers only the predictive module. As a result, the evidence supports only a load-forecasting benchmark, not the framework-level claim. Please either implement and evaluate the transfer-learning and autoscaling components or reframe the contributions to explicitly scope the paper as a forecasting study with a proposed, not yet validated, framework.","section":"Abstract; Sections IV and VII"},{"comment":"Section III-A defines the autoscaling objective as multi-step forecasting over a projection horizon p, f({ϖ_i}_{i=1}^n) ≈ {ϖ̂_i}_{i=n+1}^{n+p}, while Section V-B specifies that a fully connected output layer with a single unit is used to predict the load for the next time step. No multi-step forecasting experiments or lead-time analysis are reported, although the checkpoint-restart scaling procedure in Section IV-C-1-d introduces reconfiguration latency that requires a forecast horizon longer than one step. The paper should either add multi-step forecasting evaluation (e.g., recursive or direct strategies) and analyze the forecast lead time against the scaling latency, or revise the problem definition to a one-step lookahead.","section":"Section III-A vs. Section V-B"},{"comment":"Algorithm 2 standardizes the real-world NYCTT time series by shifting and scaling its z-scores to match the mean and standard deviation of the synthetic IoT Traffic data. This preprocessing removes the real-world distributional characteristics that the transfer-learning framework is intended to address, and it makes the \"real-world dataset\" claim in the abstract misleading. The evaluation should be repeated on the raw NYCTT series (or at least both raw and matched versions reported), and the authors should justify the normalization as a realistic benchmarking procedure.","section":"Section V-A, Algorithm 2"},{"comment":"The ARIMA model is restricted to p,q ≤ 3, d ∈ {0,1}, Nelder-Mead optimization, and 30 iterations, and the text acknowledges that these constraints \"capped its accuracy.\" The resulting comparison does not fairly represent ARIMA's performance, so the claim that GRU outperforms ARIMA is weaker than stated. Please use a standard auto_arima configuration or otherwise justify the restricted search space, and report variability across repeated runs (e.g., mean ± standard deviation over multiple seeds) for the neural models, since none of the reported numbers carry error bars.","section":"Section V-B and Section VI"}],"minor_comments":[{"comment":"The phrase \"The the three-step proactive autoscaling framework\" contains a duplicated article and should be corrected.","section":"Section I"},{"comment":"The caption contains the typo \"modesl\" instead of \"models\".","section":"Figure 6b caption"},{"comment":"The text says \"Table 1 shows the runtime of the experiments,\" but Table I lists configuration specifications (CPU, RAM, GPU, software), not runtimes; the reference should point to the table containing training-time results.","section":"Section V-B"},{"comment":"The ARIMA equation shown is a simplified ARMA(1,1) form rather than a general ARIMA(p,d,q) model; the notation should be either explicitly restricted or corrected to the general form.","section":"Section IV-A-2"},{"comment":"The explanation that all models achieve lower errors on NYCTT than on IoT Traffic is stated twice in the same section; the duplicate explanation should be consolidated.","section":"Section VI"}],"recommendation":"major_revision","confidential_remarks":"The paper is honest about the conceptual status of the transfer-learning and autoscaling components, and the title's \"Towards\" is appropriate. However, the one-step versus multi-step horizon mismatch is the most serious technical issue and should be resolved before acceptance. Depending on the journal's expectations, the authors may need to either implement the missing components or substantially reframe the paper as a forecasting study with an accompanying framework proposal."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"What you should know: this is not a validated three-step autoscaling framework. Only the GRU forecasting module is implemented and evaluated; the transfer-learning and autoscaling parts are explicitly labeled \"advanced conceptual stages\" in Section IV and again in the conclusion. That is a major gap between the packaging and the content.\n\nCredit where it is due: the paper is transparent about its limitations, which is rare. The related work survey is serviceable and covers the main DSP autoscaling threads. The design of the transfer-learning stage (DTW-based source selection plus MMD/CMMD joint distribution adaptation) is a sensible recombination of existing machinery, and the MAPE-K autoscaler with load balancer is clearly described. The forecasting benchmark, while modest, is a reasonable apples-to-apples comparison of GRU, CNN, ARIMA, and Prophet on six constructed datasets.\n\nNow the soft spots, in rough order of severity. First, the central claim is unsupported. The abstract and title present a complete solution, but the reader is told on page 4 that only the predictive model is implemented. That is not hidden, but it means the paper's actual contribution is a one-step-ahead forecasting experiment, not proactive autoscaling. Second, the problem statement in Section III requires multi-step forecasts over horizon p, yet the GRU is trained as a single-step predictor (Section V-B). There is no multi-step experiment, no lead-time analysis, and no discussion of how one-step accuracy would translate to the checkpoint-restart scaling procedure. This is a load-bearing mismatch. Third, the evaluation is thin: no error bars, no repeated runs, and ARIMA is handicapped with a deliberately constrained search space, so \"GRU beats ARIMA\" is not a strong result. Fourth, the \"real-world\" NYCTT data is rescaled to match the synthetic IoT dataset's mean and variance (Algorithm 2), which artificially narrows the domain gap and makes the RMSE numbers comparable by construction. The 1.3% SMAPE is on heavily processed data, not raw taxi load.\n\nThe authors are not fooling anyone, and the design ideas may be worth exploring, but the evidence does not support the claimed contribution. This reads like a workshop paper or a position paper, not a complete research article.\n\nMy recommendation: desk reject. The forecasting benchmark alone is not sufficient for a full paper, and the framework claims cannot be reviewed without an implementation. If the authors return with a properly scoped paper—multi-step forecasting, error bars, competitive baselines, and clearly labeled future work—it would be worth another look.","headline":"A framework paper that is honest about its conceptual status but whose title and abstract overclaim; the implemented part is a narrow one-step forecasting benchmark.","tokens_in":16426,"tokens_out":2329,"would_cite":false,"duration_ms":30629,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A lightweight GRU that forecasts edge stream load with as little as 1.3% SMAPE is the proposed engine for proactive autoscaling, backed by DTW/MMD transfer learning and a horizontal scaler.","keywords":["edge stream processing","proactive autoscaling","GRU","time-series forecasting","transfer learning","maximum mean discrepancy","dynamic time warping","operator parallelism"],"falsifier":"Train the same GRU to produce $p$-step-ahead forecasts on the IoT Traffic and NYCTT series; if SMAPE grows sharply as $p$ increases, or if the checkpoint-restart rescaling time exceeds the forecast lead time, the proactive autoscaler cannot act before load changes.","tokens_in":15430,"feed_emoji":"📈","tokens_out":5768,"duration_ms":63197,"temperature":0.7,"pith_summary":"This paper argues that proactive autoscaling for edge stream processing can be built from three pieces: a lightweight GRU network that forecasts the incoming load, a transfer-learning step that adapts an offline model to the online stream using DTW and MMD/CMMD, and a horizontal autoscaler that sets operator parallelism from the forecast. The experiments validate only the forecasting piece: the GRU reaches 1.3% SMAPE on a real-world load series and generally beats CNN, ARIMA, and Prophet across six datasets. The transfer-learning and autoscaling modules are described conceptually, so the end-to-end claim is an extension of the forecasting result rather than a demonstrated system.","feed_headline":"GRU forecast cuts edge autoscaling load error to 1.3%","feed_subtitle":"Forecast beats CNN, ARIMA, and Prophet; transfer-learning and scaling designs still await deployment tests.","key_machinery":"The carrying mechanism is the GRU's update-gate and reset-gate state update, which the paper uses to forecast load windows, combined with three supporting components: a DTW threshold that selects similar source time series, a joint loss $L_{\\text{joint}} = L_t + \\lambda_1 L_M + \\lambda_2 L_{\\text{CMMD}}$ that aligns marginal and conditional distributions in an RKHS, and the minimum-parallelism formula $\\eta_{o_i}$ that converts predicted rates into operator replicas. The GRU is the only implemented component; it takes the last 24 time steps and outputs the next load value through a single-unit dense layer.","core_discovery":"The paper's central claim is that a lightweight GRU is an accurate and cheap predictor of non-stationary edge stream load, and that such a predictor can be made to work online through a homogeneous transductive transfer-learning procedure (DTW-based source selection plus joint distribution adaptation with MMD and CMMD losses) and can drive horizontal autoscaling through a parallelism formula adapted from earlier stream-processing work. The result, as the authors present it, is that GRU load forecasts with up to 1.3% SMAPE are accurate enough to precompute operator parallelism, and that the transfer and scaling stages turn those forecasts into proactive edge scaling decisions.","pith_inferences":[],"forward_implications":["If the GRU's forecast accuracy holds online, an edge autoscaler can change operator parallelism before a load spike arrives instead of after a threshold is breached.","The measured average training and inference time of 218.8 seconds suggests the predictive model is light enough to run periodically at the edge, unlike RL policies that need thousands of training iterations.","The DTW-plus-MMD/CMMD transfer step, if implemented, would let a model pre-trained on historical data be fine-tuned on a short online sample, addressing the short retention of stream databases.","The parallelism formula plus the cloud-migration rule gives a concrete policy for stateful operators that saturate edge nodes: scale to the maximum and offload when edge latency exceeds migration plus cloud latency.","Because the current experiments are one-step-ahead, the framework's proactive promise stands or falls on a multi-step evaluation.","The 1.3% SMAPE is reported after standardizing the real-world series to match the mean and variance of the synthetic data; an evaluation on raw, unprocessed stream load would isolate how much of the accuracy comes from preprocessing.","A direct multi-step forecasting test using the same GRU and datasets is the first experiment that would settle whether the proactive claim is viable.","The load-balancer migration rule compares edge latency with migration-plus-cloud latency, but the checkpoint-restart cost in the MAPE-K execute phase is not measured; that cost determines the minimum forecast lead time the system needs."],"supporting_citations":[{"why":"Supplies the operator rate measurement and the minimum-parallelism formula that the autoscaling module adapts for edge constraints.","marker":"[7]"},{"why":"Provides the model-based RL approach for elastic edge stream processing that the paper positions itself against on training cost.","marker":"[12]"},{"why":"Supplies the synthetic IoT traffic dataset and the evaluation of load-prediction techniques for distributed stream processing.","marker":"[33]"},{"why":"Introduces the Prophet-based DSP load-forecasting service (Caladrius) that serves as a forecasting baseline.","marker":"[34]"},{"why":"Integrates ARIMA time-series forecasting into stream-processing resource provisioning and serves as the ARIMA baseline.","marker":"[35]"},{"why":"Supports the claim that DTW-based shape similarity alone misses distributional differences, motivating the MMD/CMMD component.","marker":"[44]"},{"why":"Defines maximum mean discrepancy, the kernel-based statistic used in the joint distribution adaptation loss.","marker":"[48]"},{"why":"Presents hierarchical autoscaling policies for heterogeneous stream processing that motivate the horizontal scaling and RL comparison.","marker":"[5]"}],"fun_headline_variants":["GRU beats ARIMA, Prophet, CNN for edge load prediction, 1.3% SMAPE","Edge autoscaling: GRU forecasts load to 1.3% SMAPE for proactive scaling","Lightweight GRU predicts edge stream load, outperforms classic models","GRU + transfer learning: a proactive autoscaling design for edge streams"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the GRU's accuracy in predicting the very next load value survives when the model must predict several time steps ahead, which is what the autoscaling problem's projection horizon $p$ requires.","fun_headline_variants_meta":{"raw":{"variants":["GRU beats ARIMA, Prophet, CNN for edge load prediction, 1.3% SMAPE","Edge autoscaling: GRU forecasts load to 1.3% SMAPE for proactive scaling","Lightweight GRU predicts edge stream load, outperforms classic models","GRU + transfer learning: a proactive autoscaling design for edge streams"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001775,"raw_usage":{"total_tokens":7008,"prompt_tokens":962,"completion_tokens":6046,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":578,"completion_tokens_details":{"reasoning_tokens":5954}},"tokens_in":578,"tokens_out":6046,"duration_ms":56427,"temperature":1.0,"reasoning_tokens":5954,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T15:53:26.421047+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Train the same GRU to produce $p$-step-ahead forecasts on the IoT Traffic and NYCTT series; if SMAPE grows sharply as $p$ increases, or if the checkpoint-restart rescaling time exceeds the forecast lead time, the proactive autoscaler cannot act before load changes.","supporting_citations":[{"cited_title":"Three steps is all you need: fast, accurate, automatic scaling decisions for distributed streaming dataflows,","cited_arxiv_id":null,"evidence_quote":"Supplies the operator rate measurement and the minimum-parallelism formula that the autoscaling module adapts for edge constraints."},{"cited_title":"Model-based reinforcement learning for elastic stream processing in edge computing,","cited_arxiv_id":null,"evidence_quote":"Provides the model-based RL approach for elastic edge stream processing that the paper positions itself against on training cost."},{"cited_title":"Evaluation of load prediction techniques for distributed stream processing,","cited_arxiv_id":null,"evidence_quote":"Supplies the synthetic IoT traffic dataset and the evaluation of load-prediction techniques for distributed stream processing."},{"cited_title":"Caladrius: A performance modelling service for distributed stream processing systems,","cited_arxiv_id":null,"evidence_quote":"Introduces the Prophet-based DSP load-forecasting service (Caladrius) that serves as a forecasting baseline."},{"cited_title":"Qos-and contention- aware resource provisioning in a stream processing engine,","cited_arxiv_id":null,"evidence_quote":"Integrates ARIMA time-series forecasting into stream-processing resource provisioning and serves as the ARIMA baseline."},{"cited_title":"Implementing transfer learning across different datasets for time series forecasting,","cited_arxiv_id":null,"evidence_quote":"Supports the claim that DTW-based shape similarity alone misses distributional differences, motivating the MMD/CMMD component."},{"cited_title":"Hierarchical auto- scaling policies for data stream processing on heterogeneous resources,","cited_arxiv_id":null,"evidence_quote":"Presents hierarchical autoscaling policies for heterogeneous stream processing that motivate the horizontal scaling and RL comparison."}],"review_version":1}