Schedule Repair for DAG Workflows under Link Disruptions Mohammadali Khodabandehlou∗ , Jared Coleman† , Bhaskar Krishnamachari∗ , Kevin Chan‡ ∗ Dept. of Electrical and Computer Engineering, University of Southern California, Los Angeles, USA † Dept. of Computer Science, Loyola Marymount University, Los Angeles, USA
arXiv:2609.34048v1 [cs.DC] 28 Sep 2026
‡ U.S. DEVCOM Army Research Laboratory, Adelphi, USA
Abstract—Schedules for directed acyclic graph (DAG) workflows in networked IoT systems are typically computed assuming a static or generally stable network. In contested and adversarial environments, this assumption is not valid. Links degrade and fail due to mobility, interference, and jamming. We study schedule repair: when a link disruption invalidates part of a schedule, how much of it should be rescheduled? We introduce a spectrum of repair policies that vary in repair scope, how much of the pending schedule each may move: wait out the disruption, reroute data around it, reschedule only the affected tasks locally, or reschedule all pending tasks globally. We evaluate each against an oracle and charge every repair a decision latency proportional to the extent to which it moves. Across 100 workload instances spanning synthetic task graphs, RIoTBench pipelines, and WfCommons scientific workflows, each run at five communicationto-computation ratios (CCRs) and disrupted by processes with deliberately different correlation structure, we find that no single scope wins: rerouting nearly erases isolated failures that cost waiting 30%, global repair comes within 4% of the oracle under jamming blackouts, waiting is favored under memoryless link flapping for larger and communication-heavy workloads (the scheduling analog of route-flap damping), self-healing mobility outages reward patience over reaction, and accounting for repair latency erodes large scopes first. We conclude that the scope of the repair should be adapted to the disruption process and the repair cost, rather than fixed by the scheduler. Index Terms—task graph scheduling, link failure, schedule repair, rescheduling, contested environments, edge computing
I. I NTRODUCTION Mission-critical IoT applications such as sensor fusion pipelines, stream analytics, and distributed inference are structured as task graphs (directed acyclic graphs, DAGs) executing across heterogeneous networked compute [1], [2]. Their schedules are produced by list heuristics such as Heterogeneous Earliest Finish Time (HEFT) [3] under the assumption that the network holds still, which an adversarial environment rarely honors. In contested and adversarial settings, the network is what changes: links degrade and fail under mobility, interference, and deliberate jamming. A schedule planned against a static network is then partially invalid, but it cannot simply be discarded. Tasks that started are committed, their outputs sit on particular nodes, and every transfer in flight is a sunk or lost cost. What remains is a decision about how much of the pending schedule a disruption should tear up. This paper studies that decision as a spectrum of repair policies of increasing repair scope, evaluated against an oracle that knows the disruption trace in advance. Prior work exam-
ined the analogous knob in workload dynamics. As new task graphs arrive over time, the scheduler must decide how many previously placed tasks each arrival may displace, trading off makespan against fairness and overhead [4]. In this work, the workload is fixed, and the network changes. We argue and show empirically that no single point on this spectrum is correct, because the answer depends on the structure of the disruption process and the price of repair. We make four contributions: • We define the repair ladder with precise, policyindependent disruption semantics, including a repair cost model that charges each plan a decision latency proportional to the number of tasks it moves, while the old schedule continues executing. • We build four disruption generators with deliberately different correlation structures. • We implement all of it in the ncsim simulator [5] with deterministic, seed-reproducible runs. • Across 500 variants (100 workload instances spanning synthetic structures, RIoTBench pipelines [1], and WfCommons scientific workflows [6], each at five CCRs), we show that repair scope must match both the disruption structure and the communication regime. Our findings support a ladder rather than a single winner. Rerouting nearly erases isolated failures that would otherwise cost 30% waiting time, and global repair comes within 4% of the oracle under jamming blackouts. Waiting is favored under memoryless link flapping for larger and communication-heavy workloads; self-healing mobility outages reward patience over reaction, and accounting for repair latency erodes large scopes first. II. R ELATED W ORK A. Fault-Tolerant Workflow Scheduling Fault tolerance in DAG and workflow scheduling has traditionally meant redundancy. Tasks are replicated across resources or checkpointed for resubmission, so a failure costs a re-execution rather than a lost workflow [7]. Mei et al. [8] reschedule tasks suspended by resource failures and tolerate an arbitrary number of them. Across this literature, the failing component is a processor (a VM, a cluster node, a grid site) in a wired datacenter or grid, and the response is provisioned before the failure through spare capacity. Our setting inverts
© 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.
both assumptions: the failing component is a link in a wireless network with no spare capacity to provision, and the response is reactive, with the schedule itself repaired after the disruption is observed. B. Reactive Rescheduling and Failure-Resilient Edge Scheduling A second strand asks not how to provision for failure but when to reschedule. Sakellariou and Zhao [9] reschedule a grid workflow only at selected points where measured delay exceeds the schedule’s slack, achieving most of the benefit at a fraction of the cost. The trigger, however, is drift in cost estimates for a wired grid; the question of how the rescheduling scope should relate to the location of a discrete network event does not arise. Recent work adapts classic list heuristics, HEFT included, to online execution under runtime uncertainty [10]; the trigger is again deviation from estimates rather than a discrete, located network event. Closest to our work, Cai et al. [11] reschedule dependent tasks when an edge server fails, showing that classical DAG scheduling breaks at the edge without rescheduling and contention awareness. Their repair is a single fixed policy for node failures; we study link failures and make the scope of repair the object of comparison. The same trade-off was studied under workload dynamics: when new task graphs arrive over time, partially preemptive schedulers that replan only the most recent K graphs achieve most of the makespan and utilization gains of full preemption at far lower fairness and runtime costs [4], [12]. This paper asks the complementary question for platform dynamics: when the network changes while the workload remains fixed, how much of the schedule should move? C. Repair in Networks The vocabulary of local versus global repair originates in networking. Ad hoc On-Demand Distance Vector (AODV) routing [13] repairs a broken route locally at the point of failure rather than rediscovering it end-to-end; Multiprotocol Label Switching (MPLS) fast reroute [14] pre-installs local detours because global re-optimization is too slow; and Border Gateway Protocol (BGP) route flap damping [15] suppresses reaction to links that fail and recover too quickly to be worth chasing. Pozo et al. [16] lift this question from routes to schedules: after a link failure in a time-triggered network, their self-healing protocol repairs the transmission schedule online, with only small local synthesis problems, in milliseconds. In contrast, full rescheduling takes orders of magnitude longer. Their schedules, however, allocate timedivision multiple access (TDMA) slots to frames; computation does not move. We port the local-versus-global repair question to compute schedules, where repairing means rescheduling tasks on heterogeneous nodes, with makespan rather than frame-set schedulability as the objective. D. Scheduling in Dynamic Wireless Environments Task offloading in mobile edge computing directly confronts link dynamics, and recent work is explicitly adversarial: Asemian et al. [17] combine transmission diversity
with jamming-aware scheduling to keep offloading reliable even under attack. This line, like the larger learning-based offloading literature, optimizes placement for arriving, mostly independent tasks under channel uncertainty; there is no standing multi-task schedule to repair. Bursty link behavior has been modeled using two-state Markov chains since Gilbert and Elliott [18], [19], and mobility-induced link lifetimes have been analytically characterized [20]; we use both as trace generators with controlled statistical structure. Decentralized dispatchers such as Jupiter execute task graphs on networked edge devices and must already cope with degraded links in practice [2], but do not study repair policy; simulators for networked compute have likewise treated the network as stable [5]. To our knowledge, no prior work compares repair scopes for compute task graph schedules under link-level disruptions, nor asks how the right scope depends on the statistical structure of the disruption process. III. S YSTEM M ODEL Platform. A network is a set of compute nodes V , each with speed s(v), placed in the plane and connected by directed radio links with bandwidth b(u, v). A bidirectional radio link is a pair of directions, and a wireless failure takes out the pair. Nodes execute one task at a time; concurrent transfers on a link share its bandwidth fairly. Workload. A workload is a task graph G = (T, D). Task t ∈ T has compute cost c(t) and executes on node v in time texec (t, v) = c(t)/s(v).
(1)
A dependency (t, t′ ) ∈ D carries d(t, t′ ) bytes; with t placed on u and t′ on v, delivery over the link (or multi-hop route) between them takes txfer (t, t′ ) = d(t, t′ )/b(u, v),
(2)
and is instantaneous when u = v. A scheduler assigns tasks to nodes; execution is event-driven, so start times emerge from when inputs arrive and nodes free up rather than being fixed in advance. Disruption semantics. The platform is dynamic: a disruption trace is a time-ordered sequence of link events, DOWN (the link becomes unusable), DEGRADE (it stays up at a fraction of its bandwidth), and RECOVERY. Four rules fix the semantics for every policy we compare: a transfer in flight on a failed link is aborted and later retransmitted in full; a transfer with no usable route stalls until recovery or repair provides one; tasks that started are committed and never move, so only pending tasks may be replanned; and a workload that cannot finish (e.g., a permanently severed route) is reported as a mission failure rather than folded into makespan. Repair is not free. When a policy computes a new placement at time τ moving k tasks, the plan takes effect only at τ ′ = τ + k δ,
(3)
where δ is the per-task decision latency. Policies may replan on any link event, including recoveries; the old schedule
keeps executing during the window; whatever commits in the meantime wins; and a newer plan supersedes a pending one. State observation and plan dissemination happen out of band, so δ can absorb control-plane latency as well as computation time. The number of moved tasks k is the plan’s realized repair scope, so Eq. (3) prices scope directly: global repair moves many tasks and pays a long delay, local repair moves few, and waiting pays nothing. The model incurs decision-latency costs but not the dissemination of new assignments over the same disrupted network, which we leave to future work on decentralized repair. A. The Repair Ladder When a disruption invalidates part of the schedule, the policies we compare differ in exactly one thing, their repair scope: the set of pending tasks the policy may move in response. Ordering the policies by increasing scope yields the repair ladder: • Wait (L0): nothing moves. Stalled transfers retry when the link recovers. • Reroute (L1): data detours around the failure over multihop routes; no task moves. • Local repair (L2): replan only the tasks the disruption reached (those with an undelivered input whose endpoints straddle the changed link) plus their pending descendants, since moving a task moves where its output lands; every other pending task stays pinned. • Global repair (L3): replan every pending task against the disrupted network. • Oracle: a foresight reference, not a globally optimal scheduler; it sees the complete trace but still places with HEFT. The trace makes the network piecewise-static; we execute each phase’s HEFT placement against it, add the free-repair global run, and take the best completed run. Both rescheduling policies delegate placement to the same list scheduler (HEFT [3]) with committed tasks pinned at their actual execution windows, so the policies differ only in scope, never in placement quality. A moved task re-acquires inputs already delivered to its old node, and in-flight deliveries toward it are aborted. IV. D ISRUPTION M ODELS All disruption processes compile to the same artifact, a trace of timed link events, so processes with very different structure run under identical workloads and policies; what distinguishes them is their correlation structure, precisely what we hypothesize the best repair scope depends on. Fig. 1 shows one instance’s trace under each process. The four generators are a set of disruption processes rather than a unified adversary model: single failures, flapping, and mobility represent nonadversarial platform dynamics, while jamming is adversarial and attacks communication only. In every case, the scheduler observes link-state events causally as they occur, with no knowledge of durations or recovery times; only the oracle sees the complete trace. Disruptions affect connectivity and bandwidth but do not compromise nodes, alter task execution,
falsify scheduler state, or attack the control plane, an assumption we return to in the conclusion. Single failure is the controlled-analysis case: one radio pair fails at a chosen time for a chosen duration. Flapping is the memoryless baseline. Each radio pair independently alternates exponential up and down times, with a mean time between failures (MTBF) and a mean time to recovery (MTTR), the classic two-state Markov link model [18], [19]; failures arrive without warning, independently across links, and outages are short. Mobility produces trending, temporally correlated outages: nodes follow random-waypoint trajectories [20], and each pair’s bandwidth follows inter-node distance through a stepped ramp: full within rfull , dead beyond rmax , degrading between. A failure announces itself: degradation strictly precedes disconnection, and links recover as nodes re-approach. Jamming is the adversarial case: an area jammer activates without warning, severs every radio pair in range at one instant, and recovers just as abruptly when it stops. At this deployment’s scale, the jam blankets the node cluster, so jamming is a total blackout, the fully correlated extreme the memoryless model cannot produce; targeting subsets of a larger network, in the adversarial-instance spirit of [4], [21], is future work. V. E VALUATION A. Setup We implement the disruption semantics, the repair ladder, and the four disruption generators in ncsim [5], a discreteevent simulator for DAG scheduling on networked compute that delegates placement to SAGA’s schedulers [21]. Workloads span three families: synthetic structures (outtrees, in-trees, parallel chains) with seeded weight streams, the four RIoTBench IoT stream-processing pipelines (ETL, STATS, TRAIN, PRED) [1], and three WfCommons scientific workflows (Epigenomics, Montage, Seismology) drawn from distributions fitted to real execution traces [6], with 45–102 tasks. Ten instances of each of the ten structures run on five-node networks with heterogeneous compute speeds and full-mesh radio links. Link bandwidths are set by the communication-to-computation ratio (CCR), the mean data transfer time divided by the mean task execution time: low-CCR instances are compute-bound, high-CCR ones communication-bound. Each instance runs at five CCR values (0.2, 0.5, 1, 2, 5), yielding 500 instance variants; the aggregates pool across the grid unless a figure explicitly resolves CCR. Each instance is normalized by its undisrupted makespan M0 and by its oracle makespan. Disruption processes are parameterized relative to M0 so every instance is disrupted comparably: the single failure lasts 0.5M0 ; flapping uses MTBF 0.75M0 and MTTR 0.08M0 ; mobility moves half the nodes at speeds that cross the deployment area in about M0 ; the jammer is active for 0.6M0 . The single failure is exhaustive rather than sampled: every radio pair fails at each of nine start times (0.1–0.9 M0 ), 90 cells per variant. Failures
radio pair
Single failure
Flapping (GE)
Mobility
Jamming
n3-n4 n2-n4 n2-n3 n1-n4 n1-n3 n1-n2 n0-n4 n0-n3 n0-n2 n0-n1
0.0
0.5
1.0
1.5
2.0
0.0
0.5
time / M0
1.0
1.5
2.0
0.0
0.5
time / M0
1.0
1.5
2.0
0.0
0.5
1.0
time / M0
1.5
2.0
time / M0
Fig. 1. One instance’s disruption traces, one panel per process: link state over time for every radio pair (dark: down; light: degraded; first 2 M0 shown). The correlation structures differ on purpose: an isolated outage; memoryless flapping, independent across links; mobility’s slow degradations that heal as nodes return; and jamming’s blackout, severing every link at one instant. Plan (no failure) makespan=5.55 n4
T6
n3
T0
T1
T2
T3
T13
T7
n2
T8 T5
n1
T4
T11
T9
T12
T10
T14
n0
Wait makespan=8.32 (1.50×M0 ) n4
T6
n3
T0
T1
T2
T3
T13
T7
n2
T8
T11
T9
n1
T4
T5
T10
T12
T14
n0
Local makespan=5.60 (1.01×M0 ) n4
T6
n3
T0
T1
T2
T3
T13
T5
n2
T7
T8
T9
n1
T4
T10
T12
n0
T14 T11
Global makespan=5.50 (0.99×M0 ) n4
T3
n3
T0
T1
T2
T5
T8
T6
n2
T11
T7
T9
n1
T4
T10
T12
T13
n0
T14
0
1
2
3
4
5
6
7
8
time (s)
Fig. 2. One episode, observed. The radio pair n2–n3 fails at t=1.88 (dashed; shaded until recovery at t=4.65) just as the plan’s largest transfer would cross it. Wait strands the dependent chain T5→T12→T11 until recovery (1.50 × M0 ). Local repair (applied at the dotted line) moves only the reached tasks and their descendants (hatched) and finishes at 1.01 × M0 ; global replans seven tasks and beats the original heuristic plan (0.99 × M0 ). Rerouting (not shown) detours at equal bandwidth and matches the plan exactly; the oracle here coincides with global repair.
on idle links cost nothing under any policy, so single-failure aggregates condition on the biting cells, where waiting’s makespan exceeds M0 (19% of cells). The three stochastic processes remain pooled, a quiet draw being part of the threat model. They bite in 71% (jamming), 42% (flapping), and 16% (mobility) of variants. Repair cost δ in Eq. (3) is likewise a fraction of M0 per moved task, swept from 0 to 0.5. We report the geometric mean of makespan over the oracle (ratios) across all completed instances. B. Results Fig. 2 shows a single observable episode before any aggregation: a targeted failure on a loaded link and the four outcomes the ladder produces. Waiting strands a dependent chain for the entire outage, local repair moves three tasks, and global reshuffles seven, landing below the original plan. Fig. 3
then shows the ladder resolved by CCR, Table I the per-family breakdown, and Fig. 4 the effect of charging for repair. Every run in every cell completed its workload, as these disruption processes are transient. 1) Where and when a failure bites: For one representative instance at CCR 1, the exhaustive sweep bites in 22 of 90 (pair, time) cells, exactly where planned traffic meets the outage window, and costs nothing elsewhere. This is the basis for the biting-cell conditioning above. The cells also cleanly separate the mechanisms. Rerouting erases nearly all the damage a detour can, and local repair caps the worst cells that waiting pays dearly for. Part of global repair’s advantage is re-optimization. Scheduling against any event also repairs the heuristic’s original placement, occasionally finishing below M0 .
Makespan / oracle
Single failure
Flapping (GE)
1.4
wait reroute local global
2.5
1.3 2.0
1.2 1.1
1.5
1.0
1.0 0.2
0.5
1
2
Mobility
Jamming
1.15 1.4 1.10 1.2
1.05 1.00
5
0.2
0.5
1
CCR
2
5
CCR
1.0 0.2
0.5
1
2
5
0.2
0.5
CCR
1
2
5
CCR
Fig. 3. Makespan relative to the per-variant oracle for each repair policy under each disruption process, at zero repair cost, resolved by CCR (geometric means; per-panel vertical scales; the single failure uses the biting cells of the exhaustive pair–time sweep). Communication-bound variants amplify every verdict, except under flapping, where the winner flips: rerouting is best at CCR ≤ 0.5 and collapses to 2.7× the oracle at CCR 5, where waiting wins.
Makespan / oracle
Single failure
Flapping (GE)
Mobility
Jamming local global wait reroute
1.4 1.3 1.2 1.1 1.0 0 0.01 0.02 0.05 0.1 0.2 0.5
0 0.01 0.02 0.05 0.1 0.2 0.5
0 0.01 0.02 0.05 0.1 0.2 0.5
0 0.01 0.02 0.05 0.1 0.2 0.5
Repair cost / task (frac. of M0 )
Repair cost / task (frac. of M0 )
Repair cost / task (frac. of M0 )
Repair cost / task (frac. of M0 )
Fig. 4. Makespan relative to the oracle as the per-moved-task repair cost δ grows (fractions of M0 ; non-uniform grid). Wait and reroute never move tasks and appear as cost-independent references. Free repair favors the largest scope; charging for it erodes the advantage, and by δ = 0.2–0.5 both scopes have converged onto the waiting line under every process. TABLE I G EOMETRIC - MEAN MAKESPAN OVER THE ORACLE BY WORKLOAD FAMILY ( ZERO REPAIR COST; BEST POLICY BOLD ). Family
Disruption
Wait
Reroute
Local
Global
RIoTBench
Single failure Flapping (GE) Mobility Jamming
1.35 1.06 1.03 1.11
1.03 1.18 1.03 1.14
1.08 1.05 1.03 1.05
1.09 1.04 1.01 1.04
Synthetic
Single failure Flapping (GE) Mobility Jamming
1.36 1.14 1.08 1.18
1.04 1.16 1.07 1.23
1.09 1.16 1.08 1.08
1.07 1.13 1.07 1.03
WfCommons
Single failure Flapping (GE) Mobility Jamming
1.29 1.23 1.11 1.13
1.06 2.33 1.10 1.48
1.10 1.58 1.18 1.12
1.17 1.68 1.21 1.04
2) The best scope tracks the disruption structure: Under jamming (abrupt, fully correlated, every link at once), repair pays. Global repair comes within 4% of the oracle and local within 8%, while waiting gives up 13% and rerouting 26%: a blackout leaves nothing to detour onto during the outage, and at its edges rerouting’s retries latch onto long multi-hop paths that occupy several radio links at once. Under flapping, the ordering inverts in the pooled aggregate, and waiting (1.13) beats both rescheduling policies and rerouting. Memoryless short outages are gone before a repair’s consequences are, so every reaction chases a link state that no longer holds, the scheduling analog of why BGP dampens route flapping [15].
The single failure is rerouting’s case, exactly what a detour handles outright: on the cells where the failure bites, a detour nearly erases it (1.05) and local repair stays close, while global pays for its ambition on the largest workflows and waiting pays 1.31. Mobility refutes our own hypothesis: we expected its trending, warned failures to favor local repair, but waiting and rerouting beat both repair scopes. Mobility outages selfheal as departed nodes return, so a placement that waits is a placement already repaired. Reacting merely moves tasks toward nodes that are themselves about to leave. 3) The communication regime amplifies, and can flip, the verdict: Fig. 3 resolves the ladder by CCR. Under the three stochastic processes, CCR 0.2 barely separates the policies: when transfers are cheap, a link outage has little makespan to destroy, and any response is roughly free. The biting single failures separate at every CCR, with waiting paying 25–41% throughout while a detour stays near the oracle. As CCR grows, every ordering above amplifies rather than reverses, with one exception: under flapping, the winner flips. Rerouting is the best policy up to CCR 0.5 yet collapses to 2.7× the oracle at CCR 5, where waiting wins. The mechanism is the abort-and-retransmit semantics: a compute-bound transfer completes its detour before the next flap. At the same time, a communication-bound one lives on the air long enough to be aborted repeatedly, each abort discarding the whole transfer. Jamming’s verdict, by contrast, is regime-independent, with global repair leading at every CCR.
4) Workload scale shifts the optimum down the ladder: Table I shows the aggregate hides a strong workload effect. On the small RIoTBench pipelines (∼10 tasks), global repair leads under every stochastic process, even flapping: replanning ten tasks is too small an action to backfire. On the larger WfCommons workflows (45–102 tasks), the picture reverses: under flapping, waiting decisively beats every reaction. With many pending tasks, every reaction reshuffles a large schedule and pays for it on links that already recovered. The synthetic structures sit between, with global repair best or tied under the stochastic processes, jamming most starkly. 5) Repair latency erodes large scopes first: Fig. 4 shows repair cost as an axis rather than an assumption. At δ = 0, global repair leads wherever repair helps. By δ = 0.02M0 per moved task, local repair matches or beats it under both the single failure and jamming, since global’s larger plans pay sharply at the first price step. By δ = 0.1M0 the jamming advantage is a sliver, and by δ = 0.2–0.5 both scopes converge onto the waiting line under every process. A plan that arrives after the disruption has passed never takes effect, so expensive repair degenerates into waiting. Under flapping and mobility, no price makes repair worthwhile. Interestingly, under flapping, expensive repair is milder than cheap repair, because long decision latencies allow newer plans to supersede pending ones, inadvertently damping churn. 6) The design ladder: Together, the findings distill into a single design ladder. Do nothing when disruptions are short or self-healing. Reroute around isolated persistent failures. Repair locally when the disruption is localized, repair is priced, or the workload is large. Repair globally when outages are broad, correlated, and persistent. Rising repair costs or communication intensity push every case toward a smaller scope. VI. C ONCLUSION When the network moves under a task graph schedule, how much of the schedule should move with it? We made repair scope an explicit, separately priced decision, comparing four policies (wait, reroute, local repair, global repair) under disruption processes whose correlation structures were deliberately different. The data supports a design ladder rather than a winner: match the repair scope to the disruption’s correlation structure, persistence, and price, and when in doubt react less, since every reaction chases a network state that may no longer hold. Larger workflows and communication-bound regimes both amplify the case for restraint. Two limitations remain and point at future work. First, the control plane: our scheduler observes link state. It disseminates plans out of band, an assumption strongest exactly where global repair wins, since a blackout severs the data plane in both directions. The cost sweep bounds how much control latency the advantage can withstand, but feasibility during a blackout requires a separate control channel or decentralized repair in the style of Jupiter [2]. Second, warning: our mobility results show warning alone is not enough, but proactive repair before a forecast disconnection remains open.
ACKNOWLEDGMENT This work was supported in part by ARL under Cooperative Agreement W911NF-17-2-0196. R EFERENCES [1] A. Shukla, S. Chaturvedi, and Y. Simmhan, “RIoTBench: An IoT benchmark for distributed stream processing systems,” Concurrency and Computation: Practice and Experience, vol. 29, no. 21, p. e4257, 2017. [2] P. Ghosh, Q. Nguyen, P. K. Sakulkar, J. A. Tran, A. Knezevic, J. Wang, Z. Lin, B. Krishnamachari, M. Annavaram, and S. Avestimehr, “Jupiter: A networked computing architecture,” in Proc. 14th IEEE/ACM International Conference on Utility and Cloud Computing Companion, 2021, pp. 1–8. [3] H. Topcuoglu, S. Hariri, and M.-Y. Wu, “Performance-effective and low-complexity task scheduling for heterogeneous computing,” IEEE Transactions on Parallel and Distributed Systems, vol. 13, no. 3, pp. 260–274, 2002. [4] M. Khodabandehlou, J. Coleman, N. Suri, and B. Krishnamachari, “Studying the effect of schedule preemption on dynamic task graph scheduling,” in Proc. IEEE Military Communications Conference (MILCOM), 2025. [5] B. Krishnamachari, M. Gutierrez, and J. Coleman, “ncsim: A lightweight simulator for networked edge computing with wireless interference modeling,” arXiv preprint arXiv:2605.01094, 2026. [6] T. Coleman, H. Casanova, and R. Ferreira da Silva, “Automated generation of scientific workflow generators with WfChef,” Future Generation Computer Systems, vol. 147, pp. 16–29, 2023. [7] A. R. Setlur, S. J. Nirmala, H. Singh, and S. Khoriya, “An efficient fault tolerant workflow scheduling approach using replication heuristics and checkpointing in the cloud,” Journal of Parallel and Distributed Computing, vol. 136, pp. 14–28, 2020. [8] J. Mei, K. Li, X. Zhou, and K. Li, “Fault-tolerant dynamic rescheduling for heterogeneous computing systems,” Journal of Grid Computing, vol. 13, pp. 507–525, 2015. [9] R. Sakellariou and H. Zhao, “A low-cost rescheduling policy for efficient mapping of workflows on grid systems,” Scientific Programming, vol. 12, no. 4, pp. 253–262, 2004. [10] J. Chamorro, G. Twigg-Ho, J. Coleman, T. Coleman, B. Krishnamachari, and M. Khodabandehlou, “Adapting classic scheduling heuristics for online execution under uncertainty,” in Proc. SC Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis (WORKS), 2025. [11] L. Cai, X. Wei, C. Xing, X. Zou, G. Zhang, and X. Wang, “Failureresilient DAG task scheduling in edge computing,” Computer Networks, vol. 198, p. 108361, 2021. [12] M. Khodabandehlou, J. Coleman, and B. Krishnamachari, “Scheduling dynamic IoT task graphs,” in Proc. 23rd ACM Conference on Embedded Networked Sensor Systems (SenSys), 2025, pp. 624–625. [13] C. E. Perkins and E. M. Royer, “Ad-hoc on-demand distance vector routing,” in Proc. 2nd IEEE Workshop on Mobile Computing Systems and Applications (WMCSA), 1999, pp. 90–100. [14] P. Pan, G. Swallow, and A. Atlas, “Fast reroute extensions to RSVP-TE for LSP tunnels,” IETF, Tech. Rep. RFC 4090, 2005. [15] C. Villamizar, R. Chandra, and R. Govindan, “BGP route flap damping,” IETF, Tech. Rep. RFC 2439, 1998. [16] F. Pozo, G. Rodrı́guez-Navas, and H. Hansson, “Self-healing protocol: Repairing schedules online after link failures in time-triggered networks,” in Proc. 51st IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2021. [17] G. Asemian, M. Amini, and B. Kantarci, “Reliable task offloading in MEC through transmission diversity and jamming-aware scheduling,” in Proc. International Conference on Network of the Future (NoF), 2025. [18] E. N. Gilbert, “Capacity of a burst-noise channel,” Bell System Technical Journal, vol. 39, no. 5, pp. 1253–1265, 1960. [19] E. O. Elliott, “Estimates of error rates for codes on burst-noise channels,” Bell System Technical Journal, vol. 42, no. 5, pp. 1977–1997, 1963. [20] A. Nayebi and H. Sarbazi-Azad, “Analysis of link lifetime in wireless mobile networks,” Ad Hoc Networks, vol. 10, no. 7, pp. 1221–1237, 2012. [21] J. Coleman and B. Krishnamachari, “Comparing task graph scheduling algorithms: An adversarial approach,” arXiv preprint arXiv:2403.07120, 2024.