{"id":"93e9a446-dcbc-4ee9-b878-ef8382567496","arxiv_id":"2412.20860","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"A set of deadline-driven edge-cloud scheduling heuristics (DEMS, DEMS-A, GEMS) improves on-time DNN inference completion and utility for drone fleets, adding a completion-rate QoE metric for assistive drone applications.","lead":"This paper presents deadline-driven scheduling heuristics that decide whether DNN inference tasks from drone video streams run on a nearby edge device or in the cloud. The authors test them on emulated fleets of over 80 drones and a real Tello drone, reporting more on-time completions and higher utility than baselines for a safety-relevant assistive application.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"QoE utility claims rest solely on sleep-based workloads where expected times are exact; no real-DNN or real-network experiment supports the up-to-75% QoE gain.","rationale":"The reader's weakest assumption—that percentile-based expected times are treated as deterministic bounds—is real and relevant, but the most load-bearing manifestation is in the QoE evaluation. In §8.7, GEMS's claimed QoE benefits are measured by replacing DNN execution with sleep functions whose durations exactly equal the expected times. This eliminates the cloud/edge variability that the paper itself identifies as a core challenge, and it makes GEMS's deadline-feasibility checks for migration (x + \\hat t_i ≤ deadline) trivially correct. The real-DNN emulation sections never report QoE utility, and the real-world flight sets α=1.0, which the authors admit prevents accruing QoE utility. Consequently, one of the two headline contributions—the up-to-75% QoE utility gain—has no supporting evidence from any experiment involving actual DNN inferencing or realistic network variability. If GEMS's cloud migrations are based on a 95th-percentile estimate that is occasionally exceeded, some migrated tasks will miss deadlines; the completion rate will remain below α_i, and the QoE utility will not be accrued. The proposed concrete test—running GEMS vs. DEMS with real DNN models under the same variability profiles used for DEMS-A—would directly settle whether the sleep-based results transfer. The reader's verdict of CONDITIONAL remains appropriate, but the condition should explicitly require real-DNN QoE validation rather than only addressing quantile robustness.","tokens_in":32561,"tokens_out":18760,"duration_ms":185709,"concrete_test":"Run the GEMS-versus-DEMS comparison from §8.7 using the six real DNN models of Table 1 (or at least HV, DEV, BP, CD) on the emulated Jetson Nano edge and AWS Lambda cloud, with QoE parameters α=0.9 and ω=20s, under the latency/bandwidth variability profiles of §8.5 (trapezium latency and NS3 bandwidth traces). Repeat each run 3–5 times and report mean±std of QoE utility and per-window completion rates. If GEMS's QoE utility advantage over DEMS falls materially below the reported 24–75%, or if GEMS fails to meet the α threshold in a majority of windows, the QoE claim is not supported by real execution; if the advantage persists, the sleep-based evaluation was a valid proxy.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim's QoE component—'up to 75% higher QoE utility' for GEMS—is supported only by §8.7, where 'we account for the performance of these alternate edge and cloud resources by replacing the DNN execution with just a sleep function for the relevant execution duration of the tasks.' This removes the very variability (Fig. 2) that motivates DEMS-A and that the reader identifies as the weakest assumption: with sleeps, the expected execution times t_i and \\hat t_i are exact, so GEMS's migration check (Algorithm 1 line 11, x + \\hat t_i ≤ deadline) always succeeds. In the real-DNN emulation (§8.3–8.6), QoE utility is not reported; in the real-world flight (§8.8), the authors set α=1.0 and state the setup 'does not accrue the full QoE utility due to the strict 1.0 completion rate.' Thus the headline QoE advantage has never been demonstrated under real DNN execution times or real network variability. If GEMS migrates tasks to the cloud based on a 95th-percentile \\hat t_i that is occasionally exceeded—or that does not transfer from Jetson Nano containers to Orin Nano—migrated tasks will miss deadlines, the incremental completion rate bα_i will not reach α_i, and the QoE utility (Eq. 2) will not be accrued; the reported 24–75% QoE gains could shrink or reverse.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper addresses deadline-driven scheduling of DNN inference tasks generated by drone fleets assisting visually impaired persons. It defines a QoS utility (Eq. 1) with task benefits, edge/cloud costs, and a QoE utility (Eq. 2) that rewards models whose task completion rate in a tumbling window reaches a threshold α. The proposed heuristics are: DEMS, combining EDF ordering, edge-to-cloud migration via a score function, and cloud-to-edge work stealing; DEMS-A, which adapts the expected cloud latency using a sliding-window average; and GEMS, which migrates pending edge tasks to the cloud whenever the incremental window completion rate falls below α. Evaluation uses container-emulated Jetson Nano edges, real pre-recorded drone video, six real DNNs, and AWS Lambda, plus a field test with a Tello drone and Orin Nano. The paper reports up to 88% task completion, up to 2.7x QoS utility over baselines, 16% additional utility with DEMS-A, 75% higher QoE utility with GEMS, and better drone-trajectory smoothness in the field trial.","tokens_in":32899,"tokens_out":6441,"duration_ms":59908,"significance":"If the claims hold, the paper is a useful engineering contribution: it combines realistic workloads (six contemporary DNNs on actual drone footage), an open-source scheduler, a credible container and FaaS evaluation harness, and a real drone validation. The migration/work-stealing heuristics are clearly specified and the relative comparison to several baselines is internally consistent. The main reservations are that the QoE headline is not tested under real DNN execution or network variability, the deadline-feasibility logic relies on percentile estimates used as deterministic bounds, and the empirical evaluation rests on single runs per condition. These issues are fixable with additional experiments and more cautious claims; in its present form the paper overstates the strength of the QoE result.","major_comments":[{"comment":"The 'up to 75% higher QoE utility' claim in the abstract is supported only by the sleep-based workloads in §8.7. The text says, 'we account for the performance of these alternate edge and cloud resources by replacing the DNN execution with just a sleep function for the relevant execution duration of the tasks.' This makes the expected execution times exact and removes the execution-time and network variability that DEMS-A and GEMS are designed to handle. In the real-DNN emulation (§8.3–8.6) QoE utility is not reported, and in the real-world flight (§8.8) the authors set α=1.0 and state the setup 'does not accrue the full QoE utility due to the strict 1.0 completion rate.' The QoE component of the central claim is therefore untested under realistic conditions; I recommend either adding a real-DNN QoE evaluation with network variability or explicitly limiting the QoE claim to the sleep-based emulation.","section":"§8.7, Eq. (2)"},{"comment":"The scheduler treats percentile-based expected execution times as deterministic bounds. Appendix A sets the edge time t from the average 99th percentile and the cloud time t_hat from the average 95th percentile. These values are used in JIT feasibility checks, cloud trigger times, work-stealing slack, and GEMS migration (Algorithm 1 line 11). A 95th-percentile cloud estimate means 5% of invocations exceed t_hat; a task migrated on the condition x + t_hat_i ≤ deadline can miss by construction. DEMS-A (§5.4) adapts to sustained latency shifts but not to single-task tail events, and the cooling-period reset to the static default can resurrect stale estimates. Please report the empirical distribution of observed-minus-expected times, test sensitivity to the quantile choice, and confirm that the reported gains survive. Without this, the feasibility logic is not robust to heavy tails or to transferring t_hat from container-emulated Nano edges to the real Orin Nano setup of §8.8.","section":"Appendix A; §5.1, §5.3, §5.4; Algorithm 1"},{"comment":"Each workload and condition is evaluated with a single 300-second run (or a single flight); the reported whiskers are min-max across edge containers on one host, not across independent runs. Since cloud latency, Lambda cold starts, and network shaping are stochastic (Fig. 2), single-run comparisons cannot establish the 'up to' percentages in the abstract or distinguish the heuristics from noise. I recommend several independent runs per condition with median and spread, or a clear disclaimer that the quantitative gains are from single trials.","section":"§8.3–§8.8"}],"minor_comments":[{"comment":"The expression bα_i = cλ_i/λ_i uses cλ_i, which is not defined in the algorithm; it should refer to the successful-count variable bλ_i updated on lines 4–6.","section":"Algorithm 1, line 7"},{"comment":"The sentence 'MD and CD have different configurations for the two workloads, as shown in Table 1' should refer to Table 2, since Table 2 is the one listing the WL1/WL2 configurations.","section":"§8.7, Table 2"},{"comment":"The baseline description says CLD 'should achieve 100% task completion on-time,' but the results in Fig. 8 show lower completion for intensive workloads due to network timeouts; the text should reconcile these statements.","section":"§8.2, Fig. 8"},{"comment":"The sentence '≈23% of the successful tasks in 4D-P are stolen from the cloud queue, and are all BP, forming 100% of all successfully stolen tasks for 4D-P' is confusing; it should say that all stolen tasks are BP and these constitute about 23% of successful tasks.","section":"§8.4"},{"comment":"The discussion around Fig. 12 refers to changes in the 'expected deadline'; the quantity being adapted is the expected execution time, not the deadline.","section":"§5.3, Fig. 12"}],"recommendation":"major_revision","confidential_remarks":"For the editor: the QoS scheduling contribution is solid and the engineering is substantial; the main risk is that the QoE headline and the single-run comparisons are oversold. I would ask for a real-DNN QoE experiment or a scoped claim, plus sensitivity analysis on the percentile assumption, before publication. No concerns about novelty disclosure: the relation to the authors' earlier CCGrid paper is explicit."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: the QoS scheduling story is credible and the real-drone validation is a genuine step forward. The QoE headline is the weak spot—up to 75% higher QoE utility rests entirely on §8.7 experiments where DNN execution is replaced with sleep.\n\nWhat is actually new: Eq. 2, the GEMS heuristic, updated DNN workloads, and the Tello/Orin field experiment. DEMS and DEMS-A already appeared in their CCGrid 2023 paper, and the authors say so. The emulation is unusually concrete: six real DNNs, recorded drone video, containerized Jetson Nano edges, AWS Lambda with actual costs, and a weak-scaling run with 84 drones. Code is public. Citation practice is honest; self-citation is declared and relevant.\n\nThe stress-test note is right. In §8.7, sleep functions make the expected execution times exact, so GEMS's migration check always succeeds. The 24–75% QoE gains have not been shown under real DNN latency or real network variability. The real-drone test uses α=1.0 and the authors admit the setup does not accrue the full QoE utility. So the QoE advantage is, so far, a simulation result with idealized timing.\n\nOther soft spots, in proportion. The QoS emulation appears to be single runs; whiskers are min–max across edge containers, not repeated trials, so the 2.7x and 16% numbers come without error bars. DEMS-A's w=10, epsilon=10ms, tcp=10s are chosen from empirical observation and not tested for sensitivity. And \"guarantee\" overstates what a reactive heuristic delivers. The paper's limitations section is honest about workload dependence and cost assumptions, which helps.\n\nI don't see a load-bearing logical error in the QoS part; the heuristic story is coherent and the baselines are reasonable. This deserves a serious referee. A revision should add real-DNN QoE experiments (or at least a sensitivity analysis against the sleep assumption), repeated runs with confidence intervals, and softer guarantee language. For readers working on edge-cloud scheduling for latency-sensitive drone analytics, the QoS material is worth citing; the QoE material needs the caveat.","headline":"Solid QoS scheduling study; the QoE gains are currently supported only by sleep-based simulations, so the headline needs a caveat.","tokens_in":33466,"tokens_out":3020,"would_cite":true,"duration_ms":30133,"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 deadline-aware edge-cloud scheduler for drone DNN tasks lifts on-time completion to 88% and QoS utility up to 2.7x over baselines.","keywords":["deadline-driven scheduling","DNN inferencing","edge-cloud offloading","work stealing","task migration","Quality of Experience","drone fleets","visually impaired assistance"],"falsifier":"Run the six DNN workloads on real edge and cloud hardware but feed the scheduler full latency distributions instead of the 95th/99th-percentile point estimates, or count how often actual completion exceeds those percentile bounds; if the completion and utility advantages of DEMS, DEMS-A, and GEMS over the E+C baseline shrink toward zero whenever the true tail is heavier than the benchmark tail, the central claim is refuted.","tokens_in":32322,"feed_emoji":"🚁","tokens_out":11866,"duration_ms":99972,"temperature":0.7,"pith_summary":"The paper claims that one scheduler on an edge base station can keep a fleet of buddy drones' DNN inferencing tasks on time and cost-effective by combining four moves: earliest-deadline-first ordering, migration of endangered tasks to a cloud function service, stealing slack-eligible cloud tasks back to the edge, and adapting the cloud latency estimate as conditions change. The decisions are made locally by checking whether expected execution plus queueing time meets each task's deadline, with each task carrying a benefit that includes execution cost. A window-based Quality of Experience target is added: if a DNN model's completion rate in a 20-second window falls below the user's threshold, pending tasks of that model are rescheduled to the cloud to recover the window and earn a bonus utility. In emulation with six real DNN models and recorded drone video, the heuristics complete up to 88% of tasks and earn up to 2.7x the QoS utility of baselines, and the QoE-aware variant earns up to 75% more QoE utility; on a real Tello drone with an edge accelerator, completion reaches 87% and the drone follows a proxy VIP with lower jerk and yaw error. If true, this gives a practical recipe for deadline-sensitive drone analytics on a cheap captive edge plus public cloud, with user-tunable reliability targets.","feed_headline":"Drone DNN scheduler lifts utility 2.7x and completions to 88%","feed_subtitle":"Deadline-aware dropping, migration, and work stealing keep VIP-assist drone inferencing reliable and affordable.","key_machinery":"The machinery is a set of composable deadline-feasibility heuristics in DEMS, the deadline-driven edge-cloud scheduler with migration and work stealing. On the edge, tasks are ordered by earliest deadline, and every insertion tests whether the sum of expected execution times of higher-priority tasks plus the new task's expected time $t_i$ would exceed its deadline $t'_j + \\delta_i$. The migration score $S^j_i$ decides who goes to the cloud: it is the edge-minus-cloud utility difference when the cloud would succeed with positive utility, otherwise just the edge utility. Slack $\\sigma^j = (t'_j+\\delta_i)-(t''+t_i)$ at the head of the edge queue triggers work stealing, with stolen tasks ranked by $(\\gamma^E_i-\\gamma^C_i)/t_i$ and with negative-cloud-utility tasks prioritized. The adaptive variant replaces the static cloud estimate $\\hat{t}_i$ with a sliding-window average of observed end-to-end latencies, with a cooling period to recover from dead-ends. GEMS closes the loop by tracking the incremental completion rate $\\hat{\\alpha}^x_i = \\hat{\\lambda}^x_i / \\lambda^x_i$ per model per tumbling window and pushing pending edge tasks of a lagging model to the cloud when it can still meet their deadlines.","core_discovery":"The core discovery is that the tension between maximizing on-time task completion and maximizing utility — where utility is benefit minus execution cost — can be resolved by a greedy, deadline-driven scheduler that treats the edge as the preferred resource and the cloud as a safety valve, and that this resolution survives when the cloud is slow and variable. DEMS, DEMS-A, and GEMS are not approximations of an optimal schedule; they are explicit heuristics evaluated against seven baselines, including cloud-only, edge-only, EDF and SJF hybrids, and two state-of-the-art schedulers adapted from the literature. The paper's claim is that on realistic workloads, these heuristics dominate the baselines on the two-objective frontier of task completion and QoS utility, and that GEMS additionally hits user-specified completion-rate targets in tumbling windows, which is what a VIP-facing application needs to keep navigation smooth. The real-flight result extends the claim to the full cyber-physical loop: GEMS completes up to 87% of tasks, edge-only scheduling stalls at 30 FPS, and GEMS produces the smoothest trajectory by jerk and yaw error.","pith_inferences":["An implication the authors leave implicit: their deadline/benefit abstraction is model-agnostic, so the same scheduler should transfer to other latency-sensitive drone workloads such as traffic monitoring or emergency response, as long as each app supplies a deadline, a benefit, and a window completion rate.","A testable extension: replace the fixed 95th/99th-percentile point estimates with online quantile estimates or full latency distributions; the adaptation logic suggests this would help most exactly when tails are heavy, but the magnitude is untested.","A neighboring question: the utility-maximizing edge-cloud split depends on the edge being cheaper than the cloud; if public edge services are priced like the cloud, the migration and stealing rules would need different scoring, a regime the paper itself flags as outside its sweet spot.","A corollary for practice: the QoE window mechanism turns a user's reliability preference into an enforceable SLA, which could be connected to automated negotiation of deadlines and benefits, a direction the conclusion names as future work."],"forward_implications":["A fleet of dozens of drones can be served by one scheduler per edge: weak-scaling emulations hold task completion near 83% from 21 to 84 drones.","Network variability on the path to the cloud does not have to be fatal: adapting the expected cloud latency with a sliding window recovers 16–27% utility under shaped latency and bandwidth swings while keeping task completion near the non-adaptive version.","Applications with user-tunable reliability targets can express them as completion-rate thresholds per time window, and the scheduler can enforce them without waiting for the window to fail: GEMS gains up to 75% in QoE utility by rescheduling pending tasks of lagging models.","The same scheduler that maximizes QoS also improves the physical outcome: a real drone following a VIP with GEMS completes more tasks, finishes its flight where edge-only scheduling stalls, and reports lower jerk and yaw error."],"supporting_citations":[{"why":"The authors' earlier paper that defined the deadline-driven QoS optimization problem and the DEMS heuristic that this article extends.","marker":"[22]"},{"why":"The emulation environment used to launch Jetson-Nano-like edge containers and drone containers for the comparative evaluation.","marker":"[57]"},{"why":"A QoS-aware edge DNN scheduling paper used, together with another method, to construct the SOTA 1 baseline.","marker":"[40]"},{"why":"A dynamic deadline-driven DNN execution paper combined with the previous one to form the SOTA 1 baseline.","marker":"[58]"},{"why":"An online deadline-aware edge scheduling paper adapted as the SOTA 2 baseline that DEMS must beat.","marker":"[35]"},{"why":"The companion application paper that defines the VIP drone scenario, the task models, and the real drone-following experiment.","marker":"[2]"}],"fun_headline_variants":["Drone DNN scheduler: 2.7x utility, 88% task completion","Adaptive scheduling lifts drone DNN utility 2.7x","Edge-first drone DNN scheduler beats cloud-only on utility","Real-flight GEMS drone scheduler hits 87% completion","Adaptive drone DNN scheduling: edge best, cloud fallback"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The scheduler's deadline checks depend on benchmarked 95th/99th-percentile latency estimates being treated as fixed expected durations, so if real edge or cloud latency is much more variable than those percentiles, or if the percentiles don't transfer from emulated containers to a real Jetson-class edge, the decisions and the reported gains can break.","fun_headline_variants_meta":{"raw":{"variants":["Drone DNN scheduler: 2.7x utility, 88% task completion","Adaptive scheduling lifts drone DNN utility 2.7x","Edge-first drone DNN scheduler beats cloud-only on utility","Real-flight GEMS drone scheduler hits 87% completion","Adaptive drone DNN scheduling: edge best, cloud fallback"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000802,"raw_usage":{"total_tokens":3622,"prompt_tokens":1141,"completion_tokens":2481,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":757,"completion_tokens_details":{"reasoning_tokens":2389}},"tokens_in":757,"tokens_out":2481,"duration_ms":18637,"temperature":1.0,"reasoning_tokens":2389,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T23:08:52.799628+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the six DNN workloads on real edge and cloud hardware but feed the scheduler full latency distributions instead of the 95th/99th-percentile point estimates, or count how often actual completion exceeds those percentile bounds; if the completion and utility advantages of DEMS, DEMS-A, and GEMS over the E+C baseline shrink toward zero whenever the true tail is heavier than the benchmark tail, the central claim is refuted.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The authors' earlier paper that defined the deadline-driven QoS optimization problem and the DEMS heuristic that this article extends."},{"cited_title":"Badiger, S","cited_arxiv_id":null,"evidence_quote":"The emulation environment used to launch Jetson-Nano-like edge containers and drone containers for the comparative evaluation."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"A QoS-aware edge DNN scheduling paper used, together with another method, to construct the SOTA 1 baseline."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"A dynamic deadline-driven DNN execution paper combined with the previous one to form the SOTA 1 baseline."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"An online deadline-aware edge scheduling paper adapted as the SOTA 2 baseline that DEMS must beat."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The companion application paper that defines the VIP drone scenario, the task models, and the real drone-following experiment."}],"review_version":1}