Repair strategies vary for disrupted network task schedules in iot systems
Schedule Repair for DAG Workflows under Link Disruptions
Distributed, Parallel, and Cluster Computing
Summary
Schedules that organize tasks in network-connected devices usually assume the network doesn't change much. But in real-life situations with interference or movement, communication links can fail, making parts of the schedule useless. The authors explore different ways to fix these schedules, from waiting out the problem to redoing all tasks. They found that no single fix works best for all problems; the best choice depends on the type of network disruption and how costly the repair is.
What this means in practice
- •For iot system operators: choose the best repair method for task scheduling after network link failures based on observed disruption patterns and repair costs.
- •For wireless communication engineers: design more resilient IoT workflows by adapting schedule repair strategies to different types of link disruptions and traffic conditions.
Authors
Mohammadali Khodabandehlou, Jared Coleman, Bhaskar Krishnamachari, Kevin Chan
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 communication-to-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.