{"id":"c957d9e2-b01d-4be0-bd1a-18a13a93da8c","arxiv_id":"2505.23347","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":7,"one_line_summary":"Sentinel precomputes anomaly-aware live-stream scheduling strategies in a two-stage pre/post framework and reports 70% fewer scheduling anomalies, 74% higher revenue, and 2x faster decisions on proprietary CCP traces.","lead":"This paper presents Sentinel, a two-stage scheduling system for crowdsourced live-streaming platforms that detects device and service anomalies before assigning requests to servers, and precomputes scheduling strategies to cut decision time. In replay experiments on proprietary traces from a Chinese cloud-edge platform, Sentinel is reported to reduce anomaly-linked scheduling failures by 70%, raise revenue by 74%, and double scheduling speed relative to four baselines.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 74% revenue claim rests entirely on the unvalidated Gaussian revenue surrogate of Eq. (1); if that surrogate is wrong, every reported revenue comparison is a comparison of proxies, not money.","rationale":"I read the paper as a systems contribution whose headline is a quantitative revenue improvement. The most load-bearing assumption is indeed the revenue surrogate in Eq. 1: it is simultaneously the objective being optimized and the metric used to report revenue in Fig. 8(c). The paper's motivation (sudden throughput-revenue drops from device and service anomalies) is plausible, and the anomaly detection components are evaluated with F1 scores, but the revenue function itself is never compared with actual monetary outcomes. The unspecified σ and the use of an 80th-percentile heuristic for U_opt make the surrogate hard to reproduce and easy to tune. This is not an internal inconsistency in the scheduling pipeline; it is a validity gap in the central claim. Minor issues such as the inverted wording around Eq. 4 and the typo in Eq. 14 are real but do not change the verdict. Since the reader already issued a CONDITIONAL verdict on this basis, my read does not move the verdict; it sharpens the concrete test that would settle the concern.","tokens_in":16160,"tokens_out":3658,"duration_ms":41521,"concrete_test":"Ask the authors to (a) disclose the exact σ and U_opt values used and (b) rerun the revenue evaluation with an alternative revenue model calibrated to the empirical fine data, e.g., R_raw(U) = p·B·U minus expected SLA fines from the observed device and service anomaly rates, and also with at least two σ values spanning an order of magnitude. If Sentinel's relative ranking over all four baselines is not preserved under this sensitivity check, the 74% revenue claim is an artifact of the chosen surrogate; if it is preserved, the central claim survives this concern.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central quantitative claim—'improves revenue by 74%'—is evaluated with the same revenue efficiency function F_r(U) = exp(-(U-U_opt)^2/(2σ^2)) (Eq. 1) that the Sentinel optimizer maximizes in Eq. 10. The paper reports observing a nonlinear throughput-revenue curve on 300+ servers, but it never validates Eq. 1 against actual CCP revenue net of SLA fines. Worse, U_opt is set by Eq. 12 to the 80th percentile of startup latency and error rates, and σ is never specified at all. Since the optimizer and the Fig. 8(c) revenue metric share this same ad hoc surrogate, the reported 70%/134%/17%/76% gains over Origin/GP/Greedy/MF are improvements in the surrogate, not demonstrated improvements in real revenue. If a different but equally plausible revenue model were used—for example, linear bandwidth revenue minus expected SLA fines from the empirical anomaly rates—the ranking across baselines could change. This concern targets the validity of the headline revenue claim, not the internal consistency of the scheduling algorithm.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes Sentinel, a two-stage pre/post-scheduling framework for live streaming workloads on crowdsourced cloud-edge platforms (CCPs). In the pre-scheduling stage, Sentinel detects device anomalies with a rule-based detector followed by a mixture-VGRU deep model, predicts request volumes and per-request service effects with a TCN-GCN plus cross-attention model, and solves a revenue-maximizing assignment problem to build a strategy pool. At request time, the post-scheduling stage matches actual requests to the pre-generated strategies and falls back to a heuristic for unmatched requests. Using real traces from a Chinese CCP, the authors report that Sentinel reduces anomaly frequency by 70%, improves revenue by 74%, and doubles scheduling speed relative to several baselines. The core scheduling optimization is a relaxed approximation of an NP-hard integer nonlinear program, and the revenue objective relies on a Gaussian 'revenue efficiency' function.","tokens_in":16430,"tokens_out":4265,"duration_ms":50629,"significance":"If the reported results hold, the paper makes a useful practical contribution: it is, to my knowledge, the first to explicitly integrate proactive anomaly detection into CCP scheduling for live streaming, and the two-stage paradigm is a sensible way to move expensive detection/optimization off the critical path. The measurement study of real CCP anomalies and the mixture-VGRU device detector are reasonable components, and the evaluation is grounded in substantial real-world datasets. However, the headline revenue claim rests on a single unvalidated Gaussian revenue surrogate that is used both as the optimizer's objective and as the evaluation metric, and the Origin baseline is not run under the same conditions as Sentinel. These issues are load-bearing for the paper's central quantitative claims, so the contribution cannot be fully assessed without additional validation.","major_comments":[{"comment":"The revenue efficiency function F_r(U) = exp(-(U-U_opt)^2/(2σ^2)) is used as the optimization objective in Eq. (10), and the revenue reported in Fig. 8(c) appears to be computed from the same model. The parameter σ is never specified, and no validation of Eq. (1) against actual CCP revenue net of SLA fines is provided. Consequently, the claimed 70%, 134%, 17%, and 76% revenue improvements may be improvements in a proxy rather than in real monetary revenue. I request that the authors either (a) fit and validate Eq. (1) against ground-truth revenue/SLA-fine data withheld from the fitting, including a reported σ and goodness-of-fit, or (b) report revenue using an independently measured metric and show that the ranking of methods is robust to σ and to alternative revenue models.","section":"II-C, Eq. (1), Eq. (10), Fig. 8(c)"},{"comment":"The Origin baseline is not evaluated in the same simulation as Sentinel: the text states that for Origin the authors 'do not perform additional replication but only record the relevant metrics under the real CCP.' Because Sentinel is run on a testbed built from CCP clusters, the comparison against Origin mixes environmental differences with algorithmic differences. Please rerun Origin in the same simulated testbed, or clearly label it as a historical reference and avoid drawing quantitative improvement claims from that comparison.","section":"IV-A2, Baselines, Fig. 8"},{"comment":"The road from the NP-hard integer nonlinear program to the solved linear program involves four approximations: dropping the location dimension (x_e_m_i -> x_e_i), replacing the binary service anomaly S with a sampled expectation, applying a secant outer approximation, and relaxing/rounding the integer variables. No bound or empirical optimality gap is reported for any of these steps. Since the final strategy is the rounded solution, it is unclear how much of the reported revenue gain is attributable to anomaly detection versus how much is lost or gained through the approximations. Please provide a small-scale comparison against exact enumeration or an upper bound, and report the sensitivity of the final revenue to each approximation stage.","section":"III-A3, Eqs. (10)-(14)"},{"comment":"The evaluation spans only five days and no variance or confidence intervals are reported. The anomaly-frequency and revenue differences in Fig. 8(a) and Fig. 8(c) could be within sample noise, especially for a system with roughly 16% observed anomaly frequency. Please include variability across runs or across time periods (e.g., bootstrap over the five days or multiple simulated traces) and clarify what the y-axis 'Revenue' in Fig. 8(c) measures in units.","section":"IV-B, Fig. 8"}],"minor_comments":[{"comment":"The sentence following Eq. (4) says an observation is classified as anomalous if the anomaly score is below η, but Eq. (4) states the opposite (score > η). Please correct the text to match the equation.","section":"III-A1, Eq. (4)"},{"comment":"The symbol N is used for the number of workload dimensions in Eq. (2) and also for the number of request categories in R_{t,m}; later I is used for categories in Eq. (10). This notation conflict makes the formulation harder to follow. Please harmonize the notation.","section":"Throughout, Eqs. (2)-(10)"},{"comment":"The claim that Sentinel 'reduces ineffective scheduling by an average of 70%' would benefit from an explicit definition of ineffective scheduling; as written, it is not clear whether this is the same as the anomaly-frequency reduction in Fig. 8(a).","section":"IV-B"},{"comment":"The phrase '2.0×the scheduling speed' is missing a space; it should read '2.0× the scheduling speed'.","section":"I, Abstract"}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: the P2S pre/post scheduling architecture is a real and interesting idea, but the headline revenue numbers are not yet evidence. The paper's revenue metric is a Gaussian surrogate that is also the objective Sentinel optimizes, and the evaluation appears to measure revenue with that same surrogate. So the 74% is a comparison of proxies, not money.\n\nThe genuinely new piece is the two-stage scheduling paradigm: run anomaly detection and build a strategy pool before requests arrive, then match live requests to precomputed strategies. That is a sensible way to keep anomaly detection out of the critical path, and it is the kind of engineering insight that could transfer to other time-sensitive platforms. The two-step device detector (rule-based filter plus VGRU with a mixture prior) is reasonable and the measurement analysis of device vs service anomalies uses real data. Ablations show the detector contributes, which gives some confidence the architecture is doing something.\n\nThe soft spots are real. F_r(U) = exp(-(U-U_opt)^2/(2σ^2)) is presented as a unified revenue metric after observing a nonlinear curve on 300+ servers, but σ is never specified and U_opt comes from the 80th percentile of latency and error rate. That is an ad hoc choice. The evaluation's revenue curve (Fig. 8(c)) almost certainly uses the same F_r, so Sentinel is being rewarded for pushing utilization toward a target that the optimizer itself defines. Without validation against actual SLA fines and payments, the quantitative claims are conditional. Also note the paper does not benchmark against SEER, the closest prior work; it has no error bars; and code/data are not released. The optimization relaxations are described but not formally bounded, and the location dimension is dropped then reintroduced heuristically. Minor issues: Eq. (4) says anomaly if score > η but the text says below η, and Eq. (14) expands requests by total regional share, which can distort per-category distributions.\n\nThis is a paper for a systems/networking audience, not for someone who needs the revenue results to be airtight. It deserves a serious referee: the architecture is novel enough that a thorough review is worth the time. But the authors should be pushed to validate the revenue metric against real money, add error bars, run SEER, and fix the internal inconsistencies. If the revenue metric holds up, the contribution is solid; if not, the anomaly-avoidance results still support a weaker but useful claim.","headline":"The P2S scheduling architecture is a genuine new idea, but the 74% revenue gain is an unvalidated proxy, so the quantitative claims need a lot more support.","tokens_in":16956,"tokens_out":3786,"would_cite":false,"duration_ms":35781,"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":"Scheduling live streams with proactive anomaly detection cuts ineffective scheduling by 70% and raises revenue by 74%.","keywords":["live streaming","cloud-edge computing","scheduling","anomaly detection","revenue optimization","pre-post scheduling","strategy pool","variational GRU"],"falsifier":"Run Sentinel on a platform where actual SLA fines and paid revenue are logged, and compare the realized revenue improvement against the reported 74%: if the Gaussian-derived schedule increases utilization without increasing realized revenue, the revenue model is falsified.","tokens_in":15945,"feed_emoji":"📺","tokens_out":10752,"duration_ms":95234,"temperature":0.7,"pith_summary":"The paper argues that existing schedulers for crowdsourced cloud-edge platforms underperform because they ignore anomalies, which are common and costly. It proposes Sentinel, a two-stage Pre-Post-Scheduling framework that moves anomaly detection and revenue-optimal strategy generation into a pre-scheduling stage, then uses a strategy pool to match arriving requests quickly. On five days of real-world CCP data, Sentinel reports a 70% reduction in anomaly-triggered ineffective scheduling, a 74% average revenue improvement over the platform's original heuristic, and a 2.0x scheduling speedup. If correct, this makes anomaly-aware scheduling practical at the scale and time-sensitivity of live streaming.","feed_headline":"Anomaly-first scheduling cuts failures 70%, lifts revenue 74%","feed_subtitle":"A two-stage strategy pool moves anomaly checks offline, doubling scheduling speed while raising revenue.","key_machinery":"The key machinery is the Pre-Post-Scheduling (P2S) paradigm, which separates expensive preparation from real-time decisions. In the pre-scheduling stage, a two-step device anomaly detector (rule-based variance/correlation checks followed by a variational GRU with Gaussian-mixture latent variables and Gumbel-softmax sampling) and a service-effect predictor (TCN-GCN for request volume, cross-attention decoder for revenue and anomaly status) generate a revenue-maximizing strategy by solving a relaxed linear program with branch-and-cut. The strategy is stored in a strategy pool; the post-scheduling stage matches arriving requests to the stored strategy and falls back to the original heuristic only for prediction errors. The Gaussian revenue-efficiency function $F_r(U) = e^{-(U-U_{opt})^2/(2\\sigma^2)}$, with $U_{opt}$ from the 80th percentiles of latency and error rate, is the objective that ties utilization to revenue, making the optimization tractable and the decoupling of stages possible.","core_discovery":"The central claim is that a proactive, anomaly-aware scheduling architecture can both avoid service disruptions and increase revenue in a real crowdsourced cloud-edge platform. The authors analyze real traces and find that device and service anomalies, especially device failures, cause most SLA fines. Sentinel detects device anomalies with a two-step detector (fast rules plus a variational GRU with a Gaussian-mixture prior), predicts service anomalies and request revenue with a TCN-GCN plus cross-attention model, and solves a revenue-maximization problem whose objective is a Gaussian revenue-efficiency function of utilization. The resulting strategies fill a strategy pool used at runtime, with the platform's own heuristic as a fallback for unmatched requests. In five-day tests, this reduces the frequency of both anomaly types to below 0.05 and improves average revenue by 74% over the original heuristic.","pith_inferences":["A testable extension is to replace the hand-specified Gaussian revenue function with a learned or measured revenue function from real SLA fine data; the paper does not report how sensitive the 74% revenue gain is to the exact shape of $F_r(U)$ or to the choice of $\\sigma$ and $U_{opt}$.","The P2S separation could generalize beyond live streaming to other edge-cloud scheduling tasks where anomaly-prone devices and time-sensitive decisions coexist, such as real-time machine learning inference or IoT data processing.","The paper's anomaly rate of 16.1% and its threshold tuning suggest the results may depend on the reliability characteristics of this particular CCP; applying Sentinel to a much more stable or much more unstable platform would likely require re-tuning the detector thresholds."],"forward_implications":["If the reported results hold, anomaly detection can be moved out of the real-time scheduling path, so scheduling latency becomes nearly independent of detector complexity.","The strategy-pool approach implies that each incoming request only needs a look-up, so the scheduling decision time is small and bounded.","The Gaussian revenue-efficiency function gives operators a single utilization target around which to balance load, which can be updated as new latency and error data arrive.","Because the pre-scheduled strategy is rounded from a relaxed linear program, the framework offers a computationally scalable way to approximate a hard integer optimization."],"supporting_citations":[{"why":"Provides the variational recurrent network (VGRU) that underpins the learning-based device anomaly detector.","marker":"[24]"},{"why":"Supplies the reconstruction-error anomaly score used to flag anomalous servers.","marker":"[33]"},{"why":"Motivates the Gumbel-softmax approximation for sampling the categorical mixture prior.","marker":"[31]"},{"why":"Gives the self-adaptive graph convolution used in request prediction.","marker":"[32]"},{"why":"Defines the proactive revenue-aware scheduling approach that Sentinel extends with anomaly detection.","marker":"[34]"},{"why":"Contributes the branch-and-cut solver used for the relaxed linear pre-scheduling problem.","marker":"[40]"},{"why":"Documents cross-region scheduling costs that motivate the service-anomaly prediction.","marker":"[8]"},{"why":"Serves as the revenue-aware greedy baseline in the evaluation.","marker":"[6]"}],"fun_headline_variants":["Sentinel scheduler: 70% fewer anomalies, 74% higher revenue","Two-stage proactive scheduling doubles speed, revenue +74%","Pre-scheduling anomaly checks: 70% fewer faults, 74% revenue lift","Proactive anomaly detection: 74% revenue boost, 70% fewer failures"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The Gaussian revenue-efficiency function $F_r(U) = e^{-(U-U_{opt})^2/(2\\sigma^2)}$, with $U_{opt}$ fixed at the 80th percentile of latency and error rate, is an assumed model of how utilization translates into real revenue after SLA fines; if that curve does not match reality, the reported 74% revenue improvement is an improvement in a proxy, not in actual money.","fun_headline_variants_meta":{"raw":{"variants":["Sentinel scheduler: 70% fewer anomalies, 74% higher revenue","Two-stage proactive scheduling doubles speed, revenue +74%","Pre-scheduling anomaly checks: 70% fewer faults, 74% revenue lift","Proactive anomaly detection: 74% revenue boost, 70% fewer failures"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001139,"raw_usage":{"total_tokens":4695,"prompt_tokens":877,"completion_tokens":3818,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":493,"completion_tokens_details":{"reasoning_tokens":3736}},"tokens_in":493,"tokens_out":3818,"duration_ms":29171,"temperature":1.0,"reasoning_tokens":3736,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T12:47:49.347865+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run Sentinel on a platform where actual SLA fines and paid revenue are logged, and compare the realized revenue improvement against the reported 74%: if the Gaussian-derived schedule increases utilization without increasing realized revenue, the revenue model is falsified.","supporting_citations":[{"cited_title":"A recurrent latent variable model for sequential data,","cited_arxiv_id":null,"evidence_quote":"Provides the variational recurrent network (VGRU) that underpins the learning-based device anomaly detector."},{"cited_title":"Robust anomaly detection for multivariate time series through stochastic recurrent neural network,","cited_arxiv_id":null,"evidence_quote":"Supplies the reconstruction-error anomaly score used to flag anomalous servers."},{"cited_title":"Variational inference for dirichlet process mixtures,","cited_arxiv_id":null,"evidence_quote":"Motivates the Gumbel-softmax approximation for sampling the categorical mixture prior."},{"cited_title":"Graph wavenet for deep spatial-temporal graph modeling,","cited_arxiv_id":null,"evidence_quote":"Gives the self-adaptive graph convolution used in request prediction."},{"cited_title":"Seer: Proactive revenue-aware scheduling for live streaming services in crowdsourced cloud-edge platforms,","cited_arxiv_id":null,"evidence_quote":"Defines the proactive revenue-aware scheduling approach that Sentinel extends with anomaly detection."},{"cited_title":"A branch-and-cut algorithm for the dial-a-ride problem,","cited_arxiv_id":null,"evidence_quote":"Contributes the branch-and-cut solver used for the relaxed linear pre-scheduling problem."},{"cited_title":"Aggcast: Practical cost-effective scheduling for large-scale cloud-edge crowdsourced live streaming,","cited_arxiv_id":null,"evidence_quote":"Documents cross-region scheduling costs that motivate the service-anomaly prediction."},{"cited_title":"QoE-Aware Resource Allocation for Crowdsourced Live Streaming: A Machine Learning Approach,","cited_arxiv_id":null,"evidence_quote":"Serves as the revenue-aware greedy baseline in the evaluation."}],"review_version":1}