arXiv CSopen access

IteRate: Autonomous AI Synthesis of In-Kernel eBPF Wi-Fi Rate Control Algorithms

2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

distributed-systems internet networking protocols

networking, internet, protocols, distributed systems

IteRate: Autonomous AI Synthesis of In-Kernel eBPF Wi-Fi Rate Control Algorithms James Lynch, Ziqian Liu, Snehadeep Gayen, Om Chabra, Hari Balakrishnan MIT Computer Science and Artificial Intelligence Lab Cambridge, Massachusetts, USA {jclynch,z229liu,sgayen,omchabra,hari}@mit.edu

arXiv:2605.02542v1 [cs.NI] 4 May 2026

Abstract

real-time telemetry, and learning from traces to synthesize new algorithms that adapt to prevailing conditions. Bitrate selection runs at the MAC layer at the sender, selecting a modulation and coding scheme (MCS) for each transmitted frame. Because of multipath fading, client mobility, and transient interference, the ideal MCS varies with time [6, 44]. Suboptimal rate choices lead to degraded user experience, increased latency, and spectrum under-utilization. An ideal algorithm would adapt to changing conditions and also to application requirements. Historically, bitrate selection has relied on expert-designed heuristics like Minstrel [45] and SampleRate [6]. While these algorithms are computationally lightweight and fit easily within the strict timing constraints of MAC-layer firmware, they apply rigid, one-size-fits-all logic that fails to adapt to diverse channel dynamics and changing workloads (§5). In response, recent research has turned to machine learning (ML) and reinforcement learning (RL) [26, 29, 40]. These ML approaches require heavy offline retraining, are opaque to expert engineers, and often violate the microsecond-level execution constraints of the MAC layer [29, 48]. In this paper, we ask: can we use large language models (LLMs) to synthesize practical bitrate algorithms tailored to the prevailing environment and workload? Unlike traditional black-box ML models, LLMs can generate interpretable source code [17]. This difference allows us to combine the adaptability of data-driven methods with the microsecondlevel execution speeds of classic compiled heuristics. By leveraging LLMs to write and mutate MAC-layer logic, we can plausibly generate bespoke algorithms on the fly. While recent research has applied LLM-driven pipelines to some problems in networked systems (e.g., OpenEvolve [38], Glia [17], ADRS [9]), these frameworks assume static, repeatable environments where simulators are accurate and network states are predictable. Wireless networks violate these assumptions. Real-world RF environments are inherently chaotic, and even advanced simulators struggle to capture accurate physical-layer dynamics or hardware interaction with application workloads [2, 43]. Hence, algorithms synthesized in simulation environments tend to overfit to idealized conditions and often perform poorly on real hardware [1, 2].

Wi-Fi rate adaptation remains a persistent challenge in wireless networking. Deployed algorithms like Minstrel-HT have remained largely stagnant for over a decade, relying on handtuned heuristics that fail to generalize to the complexity of modern wireless environments. We present IteRate, an autonomous research system that closes the loop on rate control development. IteRate uses a multi-agent AI architecture to conduct the full scientific cycle: formulating hypotheses, writing eBPF programs that run inside the Linux kernel, deploying them over-the-air to Wi-Fi devices, collecting fine-grained telemetry for analysis, and iterating based on experimental evidence, all without human intervention. IteRate makes three contributions. (1) a novel kernel module that exposes per-frame hardware telemetry including modulation and coding schemes (MCS) and retry counts to eBPF programs, (2) a structured agentic AI architecture employing specialized agents for algorithm design, experiment execution, and data analysis, coordinated via a hypothesisdriven research protocol with persistent knowledge, and (3) a closed-loop pipeline that automates the cross-compilation, deployment, and evaluation of in-kernel logic onto embedded Wi-Fi targets. On a 58-node testbed running five workloads. relative to the well-known Minstrel algorithm, IteRate achieves 21% faster web-page loads, 7% higher video quality of experience (QoE), and 21% higher peak throughput. Our work demonstrates that AI agents, when equipped with appropriate kernel-level hooks and a disciplined scientific workflow, can effectively automate the research required to design Wi-Fi rate controllers.

Keywords Wi-Fi, LLM, Agents, Bit-Rate Control

Introduction

We introduce IteRate, the first system to enable AI-driven, online exploration of Wi-Fi bitrate selection algorithms directly on commodity hardware. Rather than relying on expert hand-crafted heuristics, IteRate operates as an embedded researcher, orchestrating on-device experiments, analyzing 1

Lynch et al.

(2) Programmable MAC-Layer architecture: We implement a novel framework that allows the safe, subsecond deployment of machine-generated code into the kernel-space transmission path of commodity Wi-Fi hardware. (3) System validation and case studies: We demonstrate IteRate’s efficacy by autonomously synthesizing and evaluating multiple rate controllers and conducting automated experiments on a 58-node Wi-Fi testbed. We evaluate IteRate across 5 representative workloads capturing interactive voice, web transfers, adaptive video streaming, and bulk downloads. Relative to the well-known and widely used Minstrel algorithm, IteRate achieves 21% faster web-page loads, 7% higher video QoE, and 21% higher peak throughput. Compared to policies produced by OpenEvolve, IteRate reduces web-page completion time by 52% and improves video QoE by 12%, while increasing peak throughput by 10%.

IteRate enables the online synthesis and evaluation of Wi-Fi rate control algorithms within a live network environment. Rather than using offline simulators, IteRate provides a programmable experimentation environment where newly generated algorithms are rapidly deployed, executed on the packet transmission path, and evaluated using real wireless traffic by AI agents to produce new candidate algorithms. IteRate decouples high-level algorithm synthesis from lowlevel execution. An LLM-driven agent system operates as an autonomous researcher that observes real-time network telemetry, proposes candidate rate-control policies, and iteratively refines them based on empirical feedback. IteRate then transforms these policies into executable code that is safely injected into the live datapath, enabling microsecond-scale execution while preserving system stability. To support this workflow, IteRate provides three capabilities: (1) An autonomous synthesis loop: This component functions as the system’s agentic AI layer, moving beyond static logic to a continuous cycle of hypothesis and experimentation. By treating the live network as the evaluation environment, IteRate autonomously generates, tests, and evaluates candidate algorithms. It learns from live traces and hardware feedback, allowing the AI agent to refine its logic based on the observed consequences of its decisions. (2) High-fidelity wireless telemetry: To enable meaningful learning, IteRate must see what the hardware is actually doing. This component provides the groundtruth visibility required to close the loop between algorithms (code) and performance. It exposes realtime transmission outcomes and underlying hardware behaviors that are typically invisible to the operating system. Without this high-fidelity window into the physical-layer performance, the synthesis loop would remain blind to the hardware idiosyncrasies that dictate real-world success. (3) A programmable environment: This component provides the agility needed to turn theoretical insights into operational code. By replacing rigid rate controllers with a policy-driven engine, IteRate can deploy dynamically generated algorithms into the transmission path in under one second. This environment is designed for seamless adaptation, allowing the system to update its logic without disrupting ongoing traffic or disconnecting stations, thereby enabling continuous optimization in a live network.

The software developed in this work will be open-sourced to enable further research.

2 Background & Related Work 2.1 Challenge of Bitrate Selection MAC-layer bitrate selection is the problem of selecting the transmission bitrate (i.e., MCS) used for each wireless frame. Each MCS determines the number of transmitted bits per symbol and the coding rate, which together determine the effective data rate. Higher MCS values transmit more bits per unit time but require a cleaner channel; lower MCS values are more robust but sacrifice throughput and latency. An ideal rate-maximizing system must operate at the boundary of channel capacity. If the sender overestimates the channel quality and chooses an overly aggressive MCS, frames are corrupted and must be retransmitted, consuming additional airtime and increasing latency. If the sender underestimates the channel and chooses a conservative MCS, transmissions succeed but waste spectrum. Bitrate adaptation is a control problem under uncertainty: the system must continuously infer the best transmission rate from noisy, delayed feedback while balancing the competing costs of packet loss and underutilized capacity. An ideal system should also adapt to the needs of the applications using the system; e.g., an interactive game might care less about throughput and more about interactive latency (thus favoring bitrates that reduce the number of link-layer retransmissions), while a bulk data transfer might focus on throughput.

This paper makes the following contributions: (1) Autonomous research orchestrator: We design an LLM-driven agent system capable of independently forming hypotheses, executing live experiments, and interpreting telemetry to refine rate-control logic. 2

IteRate : Autonomous AI Synthesis of In-Kernel eBPF Wi-Fi Rate Control Algorithms

State-of-the-Art Algorithms

Average throughput (Mbps)

2.2

Existing bitrate algorithms can be categorized into classic heuristics [6, 32, 45], reinforcement learning [26, 27, 40], and machine learning [29, 48]. Most prior work focuses on one of three primary objectives: 1. General-purpose adaptation: This line of research focuses on developing robust, single-policy solutions capable of handling diverse environments and traffic patterns [32, 44, 45]. The Linux default, Minstrel [45], maintains success statistics for each rate and periodically probes alternatives to identify better options. It selects the bitrate that maximizes the product of the bitrate and success probability at that bitrate. More recent approaches propose RL bandit algorithms such as Thompson Sampling [27] to accelerate adaptation by balancing exploration and exploitation through systematic uncertainty estimates. These methods rely on deployment-agnostic policies that react to immediate conditions rather than specializing in the specific nuances of a given workload.

Minstrel

24 20 16 12 8 4 0

Env.A-trained

Env.B-trained

Best in Env. A Best in Env. B

Environment A

Environment B

Figure 1: Bitrate adaptation performance depends on the environment and workload. Algorithms tuned for one wireless environment often perform poorly in others due to differences in channel conditions and interference. than raw goodput [7, 10, 11, 33, 34]. For example, ADR-X aims to reduce packet losses for gaming devices [48]. Other application-specific or traffic-aware designs target multimedia streaming, VoIP/VoWLAN QoS, and congested mixedtraffic settings [3, 7, 10, 11, 18, 33]. To optimize applicationlevel metrics, these schemes exploit structure in the underlying workload—e.g., deadlines, loss sensitivity, interactivity, or traffic mix—rather than optimizing a single applicationagnostic metric [33, 47, 48]. Our goal in this paper is to design a system that can autonomously specialize algorithms to the specific deployment environments and application regimes. As we’ll show in §5, our system is able to select different algorithms based on how they perform in a unique environment.

2. Environment-specific deployment: A second line of work designs algorithms for a specific deployment setting or hardware regime [3, 8, 16, 21, 22, 28, 30, 31, 34, 35, 37, 39, 41, 42]. For example, LLRA [34] targets home networks, SmartRate [28] is built for office/conference-room contention, RaCA [21] and Damysus [41] specialize to dense indoor deployments, and MuDRA [16] targets auditorium-scale delivery. Each modifies the bitrate controller to exploit deploymentspecific structure that a general-purpose scheme like Minstrel ignores. For instance, in Figure 1, we present the ability for an algorithm explored in different environments to generalize across environments. In Environment A (a cleaner, more constrained environment), we observe that both of our explored algorithms outperform the default Minstrel algorithm, but the algorithm tuned in that environment performed better. However, in Environment B, only the algorithm that was finetuned was able to substantially outperform Minstrel.

2.3

Human-in-the-Loop Rate Tuning

Many Wi-Fi deployments already assume a human-in-theloop tuning workflow. In these systems, network operators do not treat bitrate behavior as fixed; instead, they inspect telemetry and revise rate-related policies as conditions change. For instance, Extreme’s WiNG allows administrators to select specific algorithms [15], while Juniper’s Mist provides predefined bitrate profiles and custom settings [25]. This decision-making process follows a standardized operational pattern: access points (APs) collect telemetry at the edge and export it to a centralized management plane such as Meraki Health [14], Mist Cloud [23], or Cisco Catalyst Center [12], where engineers diagnose pathologies and update network configurations. Recent products from Juniper [24], Cisco [12, 13], and HPE Aruba [19, 20] automate parts of this loop, using AI/ML to tune radio parameters like channel selection and transmit power. Our work explores whether this same architecture of trace collection and centralized analysis can be pushed

3. Application-specific: The third line of research aims at providing algorithms designed to optimize metrics for specific applications [3, 7, 10, 11, 18, 33, 34, 47, 48], in the sense that the “best” bitrate policy depends on an application-level objective. Prior work has shown that application performance under a given bitrate scheme varies substantially across workloads such as multimedia streaming, bulk transfer, and web browsing, and that raw link-layer throughput is often an insufficient proxy for end-to-end utility [18, 47]. As a result, some algorithms are designed primarily around packet success probability or burst-loss reduction, others around throughput or expected transmission time, and still others around delay-sensitive or interactive workloads where tail latency, jitter, or conversational quality matter more 3

Lynch et al.

OpenEvolve Running Best

Better than OpenEvolve result but gets rejected!

Agent Server

50.0

Mean RSSI (dBm)

Throughput (Mbps)

Throughput (Mbps) Mean RSSI (dBm)

3 2

eBPF ELF, cmds

telemetry, stats

MQTT Broker

57.5 1

30 40 50 60 Iterations over Time

70 ···

Figure 2: Environmental noise corrupts evolutionary scoring in live wireless settings. Throughput (blue) closely tracks RSSI (red) across OpenEvolve iterations, causing protocols evaluated during favorable periods to appear superior. OpenEvolve selects protocols due to RSSI improvements (yellow lines) rather than protocol gains. A random protocol evaluated under worse channel conditions (green marker) achieves higher true performance but is rejected, illustrating how channel variability can mislead evolutionary search.

Wi-Fi Device

Kernel Module

Mgmt Daemon

···

Figure 3: System topology. Wi-Fi devices execute rate policies and stream per-frame telemetry to the centralized agent server, which hosts the LLM orchestrator that synthesizes algorithms and deploys compiled eBPF objects to the edge. (throughput, blue) and channel quality (RSSI, red). Because throughput closely tracks RSSI, protocols evaluated during favorable channel periods appear superior even when the improvement is unrelated. OpenEvolve selects candidates based on transient channel conditions rather than genuine algorithmic gains. In fact, when we later tested a randomly generated protocol, we observed that it could outperform the previously selected “best” protocol. Instead, as we show in the next section, our goal is to equip the evolutionary agent with an explicit understanding of the wireless environment so it can reason about why a method works, not just whether it performs well. By embedding domain insights similar to a network researcher, the agent can make more principled design decisions, adapt more robustly to changing conditions, and avoid discarding good strategies due to transient network fluctuations. This is the same philosophy advocated in Glia [17], but the differences lie in the agentic structure and in the use of the live network as the experimentation platform rather than a simulator.

much further to the automatic near-real-time synthesis and deployment of MAC-layer bitrate selection algorithms.

2.4

Session Store

55.0

1 0

LLM Orchestrator

52.5

Code Evolution Challenges

One natural approach to solve this problem is to use LLMdriven code-mutation (e.g., OpenEvolve [38]) or reasoning pipelines [17]. However, existing evolutionary pipelines [9, 17, 38] rely on simulators to ensure scoring consistency. While simulators provide the controlled environments necessary to isolate algorithmic performance, they often fail to capture the disorderly, non-stationary realities of physical RF channels and the idiosyncrasies of Wi-Fi hardware [1, 2]. Moreover, simulators struggle to faithfully model the causal relationships between low-level bitrate adaptations and behaviors at higher protocol layers because small changes can propagate into complex network-level effects [4]. Our approach is instead to evolve the bitrate selection algorithm directly online in the actual wireless environment. However, the key technical challenge is that prior works, such as OpenEvolve, rely solely on end-to-end scoring functions to grade candidate programs. This approach works well in controlled, reproducible simulations. However, in real wireless environments, changing traffic patterns and transient interference introduce environmental noise, causing such evolutionary search to degenerate into a near-random walk. Fig. 2 illustrates this effect using an OpenEvolve run where each iteration evaluates a candidate protocol on a live wireless link (§4) while recording both the application metric

IteRate Architecture

IteRate is an autonomous, LLM-driven research platform that dynamically synthesizes, deploys, and evaluates MAC-layer rate-adaptation algorithms directly on a wireless network. As shown in Figure 3, the system consists of a centralized management server and a fleet of distributed Wi-Fi devices. The devices act as execution engines that run the selected bitrate policies and stream telemetry back to the server. All computationally intensive tasks (i.e. the agent discovering and refining new algorithms) are handled centrally by an autonomous research orchestrator. 4

IteRate : Autonomous AI Synthesis of In-Kernel eBPF Wi-Fi Rate Control Algorithms

Safety. The architecture enforces strict isolation to enable safe experimentation without compromising stability. IteRate separates the compute-intensive, non-deterministic reasoning of the LLM from the critical on-device software executing the policy in real-time. This separation is essential because LLMs may hallucinate or make logical errors, and even minor hardware misconfigurations can trigger network outages that take minutes to recover from. To safely deploy an autonomous agent in low-level network control, IteRate implements a three-layer safety model:

(3) Design: Formulate an experimental plan isolating independent and dependent variables (e.g., isolating payload size while varying the MCS). (4) Execute: Delegate the operational plan to an Experiment Runner subagent (described below), which orchestrates simultaneous traffic generation and background telemetry collection. (5) Interpret: A Data Analyst subagent (described below) computes effective metrics; the Scientist writes a formalized finding supported by specific empirical evidence. (6) Iterate: Update the hypothesis status in the database and refine the approach based on accumulated evidence.

(1) All agent-generated code must pass the kernel’s eBPF static verifier before execution, ensuring memory safety, bounded runtime, and protection against kernel crashes. (2) The reasoning agent cannot directly modify device state, ensuring strict privilege separation. (3) All configuration changes are recorded in an ephemeral undo log and automatically reverted on shutdown, preventing persistent misconfiguration (§4).

3.1

To execute each step, the Scientist invokes a dedicated tool that records the action, intermediate reasoning, and conclusions to a persistent store (§3.1.4). 3.1.2 Hierarchical Subagent Topology. To execute each of these steps, the Scientist requires different expertise, and each step entails different risks, especially because experiments are conducted on live networks. To manage these tasks, we decompose the Scientist into structured subagents, each handling a specific function. This separation reduces risk, clarifies responsibility, and manages the Scientist’s context window while keeping the overall process coordinated as a single research workflow:

The Autonomous Research Agent

IteRate’s design mimics the workflow and intuition of wireless networking researchers. The IteRate agent does not optimize metrics blindly; instead, it observes link behavior, forms hypotheses about channel dynamics and protocol interactions, designs algorithmic modifications grounded in those observations, and tests them against empirical evidence. Like a human expert, the agent reasons about causality, iterates on promising ideas, and abandons ineffective ones based on principled analysis rather than noisy outcomes. The goal is to embed the investigative, hypothesis-driven skill set of wireless networking researchers into an automated, scalable system. At the top of our system is a unified Scientist tool calling agent responsible for the full research loop. It designs algorithms, plans experiments, deploys them, collects data, and analyzes results.

• Experiment Runner: Orchestrates the physical testbed by executing A/B tests, commanding throughput sweeps, and managing background telemetry collection. • Algorithm Designer: A synthesis agent that operates offline to produce ideas and express them in eBPF C code, adhering to kernel verifier constraints. • Data Analyst: Computes effective metrics, identifies performance anomalies (e.g., MCS knee points), and generates cross-environment comparisons from stored telemetry. • Network Engineer: Manages physical and logical hardware configurations via configuration updates that are automatically reverted on session teardown. Each subagent is kept as a stateless agent with a unique, fixed tool subset (breakdowns in Appendix A). The Scientist delegates via a task(description, subagent_type) tool call, passing a natural-language task description that includes all required context. Because subagents are stateless (fresh LLM context per invocation), the Scientist must include all relevant context in each call, while subagents return structured JSON results. This design isolates strategic reasoning from operational execution and ensures that no subagent accumulates stale state across tasks.

3.1.1 Scientist State Machine. To ensure this exploration process remains structured and reliable, we model the research workflow as a growing process. Since unbounded LLM agents are prone to logical drift and stalled execution [5], the Scientist agent is prompted to follow a flexible sixstep research protocol that formalizes the progression from hypothesis to validated results: (1) Orient: Query testbed status, review prior findings from session memory, and search external academic literature. (2) Hypothesize: Propose a formally testable hypothesis containing a falsifiable statement, a specific performance prediction, and a physical rationale.

3.1.3 Tool-Use API and Data Delegation. All subagents interface with the physical network via a tool server that exposes over 90 dynamically loadable tools, organized into 15 capability groups (rate control, telemetry, traffic generation, 5

Lynch et al.

privilege boundary task()

Scientist

Experiment Runner

1. Orient

Tool API

results

2. Hypothesize

Algorithm Designer

90+ tools 15 groups

Data Analyst

observe actuate stimulate

MQTT Broker cmds

3. Design 4. Execute 5. Interpret

telem

Wi-Fi Devices Mgmt Daemon

6. Iterate

Network Engineer Kernel Module findings

telemetry

Session Store (SQLite) query

Figure 4: Agentic pipeline. The Scientist agent drives the research loop but cannot mutate device state. It delegates operational tasks across a privilege boundary to scoped subagents, each with access to a restricted subset of the 90+ tool API. Raw telemetry flows directly into the session store, bypassing the LLM context. eBPF management, experiment orchestration, etc.). Tools map high-level intent into deterministic MQTT commands across three vectors: observation (telemetry querying and statistics), actuation (rate configuration, policy switching, BPF deployment), and stimulus (coordinated bidirectional traffic generation). A critical design constraint is that MAC-layer telemetry generates tens of thousands of per-frame records per minute, which would quickly exhaust any current LLM’s context window. IteRate enforces strict data delegation: raw telemetry payloads never pass through the LLM context. Instead, telemetry is streamed directly from edge devices to a persession relational datastore. The analyst agent assesses this data through tool calls that return compact statistical summaries.

it is loaded. If validation fails, the verifier’s error trace is returned to the algorithm designer subagent for automated debugging. This execution pipeline ensures that only safe, verifiable programs run on the device while enabling rapid iteration.

Implementation

IteRate runs bitrate algorithms directly inside the Linux WiFi transmission datapath, allowing the system to observe link outcomes and update transmission policies at frame-level granularity. Traditionally, Linux Wi-Fi drivers rely on a pluggable rate control module that selects the modulation and coding scheme (MCS). We replace the default Minstrel-HT controller with a programmable module that allows the centralized agent to deploy and update rate-selection algorithms on a 58-node commodity hardware testbed. The bitrate algorithm periodically runs and updates a stored MCS lookup table. Then, before a frame is transmitted, the kernel consults this table to select the transmission rate. After the transmission completes, the driver reports the outcome (success or failure, retry count, and signal strength). Our module exposes this per-frame feedback to a policy engine, which updates its internal state and determines the rate for subsequent transmissions. Policies may be implemented as built-in algorithms or as dynamically loaded eBPF programs, enabling the agent to deploy new rate-selection logic without rebooting devices or modifying firmware.

3.1.4 Relational Memory and Cross-Session Lineage. To support long-horizon research beyond the LLM’s limited context window, the Scientist is equipped with a tool that commits intermediate results and learned insights to a persistent SQLite datastore. The agent is instructed to record its findings after each step of the research loop, creating a structured, relational memory that survives across sessions and enables cumulative progress. 3.1.5 Execution. During execution, the agent generates eBPF code that complies with kernel verifier constraints (e.g., bounded loops, controlled stack usage, pinned maps). The code is cross-compiled centrally and deployed to the router (§4.5). The kernel verifier then validates the program before 6

IteRate : Autonomous AI Synthesis of In-Kernel eBPF Wi-Fi Rate Control Algorithms

The implementation consists of five components: (1) a kernel-level programmable rate control module, (2) an inkernel eBPF execution environment for policy logic, (3) a telemetry subsystem for collecting transmission outcomes, (4) a lightweight management daemon that bridges devices to the centralized agent, and (5) an automated build and deployment pipeline for synthesizing and deploying new algorithms across the testbed. Together, these components enable the agent to observe link behavior, generate candidate algorithms, deploy them safely to edge devices, and evaluate their performance in real wireless environments.

4.1

for subsequent frames. On our hardware, we observe that the per-packet path produces unreliable behavior at higher MCS indices. We therefore use the cached rate table mode, ensuring consistent rate enforcement across transmissions.

4.2

eBPF Execution Environment

Rate adaptation decisions occur on microsecond timescales within the transmission path, making user-space control too slow due to scheduling latency and kernel-user round trips. To support real-time adaptation, the BPF policy mode executes rate-selection logic directly inside the kernel’s TX completion path. On each frame completion, the program observes transmission outcomes and updates rate decisions at frame granularity. Before deployment, each eBPF program is statically verified by the Linux kernel to guarantee memory safety and bounded execution. The verifier ensures that programs terminate, access only valid memory regions, and respect stack limits, preventing faulty policies from destabilizing the device. This allows dynamically generated algorithms to execute safely in the datapath. Shared Maps. The module exposes three persistent BPF array maps, each pinned to /sys/fs/bpf/ for cross-process sharing between the kernel datapath and the management daemon:

Programmable Rate Control Module

The edge datapath in IteRate is a custom Linux mac80211 rate control module that replaces the default Minstrel-HT algorithm. The module registers as a standard rate_control_ops provider and implements the get_rate() and tx_status() callbacks that the Wi-Fi stack invokes before each frame transmission and after each transmission completion, respectively. This placement allows the system to observe per-frame transmission outcomes and update rate decisions at frame-level granularity. Policy Engine. Rather than enforcing a single fixed algorithm, the module implements a policy dispatch architecture with five interchangeable policies: • Fixed: A single MCS for all stations and frame types. • Per-station: Individual rate overrides per MAC address, enabling controlled per-link experiments. • Round-robin: Cycles through a configurable MCS list, transmitting 𝑁 frames at each rate before advancing. This policy is used for systematic rate sweeps and training data collection. • Frame-type: Separate rates for management, control, and data frames, allowing the agent to protect control-plane reliability while aggressively tuning data rates. • BPF: Rates driven by an eBPF array map, enabling fully autonomous in-kernel rate adaptation (§4.2). Policies can be switched at runtime via a debugfs control interface without disrupting active associations. To avoid pushing rate tables on every frame, the module maintains a global generation counter. When the configuration changes, the generation counter increments, and the per-frame hot path updates the driver’s rate table only when a station’s cached generation becomes stale, amortizing update costs across thousands of frames. Rate Table Integration. Wi-Fi drivers typically support two mechanisms for supplying transmission rates: a perpacket path, where the rate is embedded in each frame’s TX descriptor, and a cached rate table path, where rates are pushed once into the driver’s per-station cache and reused

• Rate Map (128 entries × 8 B): Indexed by wireless client ID (WCID). Each entry specifies the target transmission parameters (MCS, spatial streams, bandwidth, guard interval, PHY mode) and a valid bit. The kernel reads this map on every get_rate() invocation to determine the next transmission rate. Because BPF map writes do not increment the module’s rate_generation counter, the BPF policy handler independently detects rate changes by comparing the current map entry against the previously applied rate and resetting the push state when they differ. • Stats Map (128 entries × 48 B): The kernel periodically updates this map with aggregated transmission statistics, batching writes every 64 TX completions per station. Entries include cumulative transmission counts, an EWMA packet error rate (PER), retry counts, and signal strength. These summaries provide BPF programs with statistical context while minimizing datapath overhead. • Algorithm Map (128 entries, variable size): Private perstation state used by rate adaptation algorithms (e.g., perMCS delivery histograms, probing counters, or EWMA windows). This map is created and pinned by the management daemon using raw bpf() syscalls to avoid BTF type dependencies absent on our embedded MIPS kernels. Map pointer swaps (e.g., when the management daemon attaches a new map or detaches an old one) are RCUprotected. The module publishes new map references using 7

Lynch et al.

• Metadata: WCID, frame length, RSSI, monotonic sequence number, kernel timestamp.

rcu_assign_pointer() and waits for a grace period before releasing old maps, allowing the per-frame TX path to read map pointers lock-free via rcu_dereference(). Individual map entry updates rely on the BPF subsystem’s atomic operations and therefore do not require RCU. Per-Frame TX Context. When a BPF program is attached, the kernel invokes it after each frame completion with a 120-byte context structure containing 15 fields (Table 2). The context includes transmission outcomes, retry counts, signal strength, and both configured and hardware-reported rate information. The hw_mcs_used and hw_rate_flags fields expose the actual rate used by the radio firmware rather than the rate requested by the module. This distinction is important because the MT76x02 radio automatically falls back to lower rates when retries are exhausted, including cross-PHY transitions from high throughput (HT) to legacy OFDM. The standard mac80211 rate control interface does not expose this fallback rate separately. Our module captures the hardware-reported rate directly from the driver’s TX status before any subsequent processing. Without this visibility, rate adaptation algorithms attribute successful delivery to the configured MCS even when the frame was recovered by firmware fallback, grossly overestimating the reliability of aggressive rates. Verifier Safety. All eBPF programs must pass the kernel’s static verifier before execution. The verifier guarantees bounded execution time (no unbounded loops), memory safety (no out-of-bounds accesses), and compliance with the BPF stack limit (≤512 bytes). A subtle constraint arises on embedded kernels without BPF Type Format (BTF) support: values loaded from BPF maps are treated by the verifier as unconstrained scalars. For example, a __u8 MCS index loaded from the algorithm map and used as an array index is conservatively treated as a value in the range (0, 255), even if the program logic guarantees a smaller bound. Developers must therefore emit explicit bounds checks before every map-derived array access. We encode this constraint in the static linter described in §4.5.

4.3

The ring buffer is read by the management daemon through a binary debugfs interface. Each read atomically snapshots the head and tail pointers, copies available entries (handling ring wraparound with two memcpy calls), and advances the tail, providing zero-copy transfer to userspace. At typical traffic rates (1,000–10,000 frames/s), the buffer provides 0.4–4 s of history before wraparound. The management daemon polls at 1 s intervals; at the high end of this range, some entries may be overwritten before they are read. This is acceptable because the BPF program’s algorithm map maintains its own cumulative per-station statistics independently of the telemetry ring, and the agent’s analytical tools operate on statistical aggregates rather than individual frame records.

4.4

Management Daemon

Each Wi-Fi device runs a lightweight management daemon (≈8k lines of C) that bridges the kernel module to the centralized agent over Message Queuing Telemetry Transport (MQTT). The daemon operates as a single-threaded asynchronous event loop. Command Routing. The daemon subscribes to over 40 MQTT command topics covering rate configuration, BPF map management, wireless interface lifecycle, traffic generation, packet capture, and Unified Configuration Interface (UCI). Each command produces a structured acknowledgment containing the result or a detailed error message, enabling the agent to confirm that changes were applied before proceeding with experiments. BPF Lifecycle. The daemon manages BPF artifacts using a dual-library strategy dictated by embedded kernel constraints. Map creation uses raw bpf() syscalls to avoid BTF type dependencies absent on MIPS targets; program loading uses libbpf for ELF parsing, relocation, and map binding. Programs arrive as base64-encoded ELF objects over MQTT and are loaded asynchronously on a background thread. On verifier failure, libbpf’s output callback captures the verifier log (truncated to 3 KB) and returns it to the agent for autonomous debugging. Telemetry Streaming. On a configurable interval (default 1 s), the daemon reads the kernel’s binary telemetry ring buffer, converts entries to JSON, and publishes them to the MQTT broker. A separate stats publication (default 5 s) provides per-station aggregate statistics including delivery ratios, retry distributions, and signal strength. Raw telemetry flows directly into the agent’s relational datastore without passing through the LLM context window. Ephemeral Configuration. All UCI configuration changes (wireless interface creation, network settings) are tracked in

Telemetry Subsystem

High-fidelity telemetry is essential for closing the agent’s observe-hypothesize-experiment loop. The module maintains a per-PHY lock-protected ring buffer of 4,096 entries (approximately 80 KB), recording a compact 20-byte entry for every transmitted frame: • Intended rate: The MCS index and flags configured by the active policy. • Hardware rate: The actual rate reported by the driver in TX status. The module captures this from the raw status structure before any subsequent processing. • Outcome: Success/failure, retry count, aggregation flag. 8

IteRate : Autonomous AI Synthesis of In-Kernel eBPF Wi-Fi Rate Control Algorithms

4.6

an in-memory undo log. On daemon shutdown or session teardown, all changes are automatically reverted, preventing permanent device misconfiguration from failed experiments. Individual changes can be selectively persisted or reverted via MQTT commands.

4.5

Testbed

We deploy IteRate on a fleet of 58 Hak5 Wi-Fi Pineapple Mark VII devices distributed across multiple floors of an urban university campus building. Each device is a commodity 802.11n router running OpenWrt with a Linux 6.6 kernel, equipped with a MediaTek MT76x02 2.4 GHz radio. The devices operate in HT mode with MCS 0–7 on a single spatial stream at 20 MHz bandwidth, providing PHY rates from 6.5 to 65 Mbps. Link distances are highly variable, ranging from adjacent rooms on the same floor to cross-floor placements separated by concrete and steel, producing a wide spread of signal conditions. The 2.4 GHz band is shared with the building’s production Wi-Fi infrastructure and neighboring networks, exposing experiments to realistic co-channel interference. The centralized agent server communicates with all devices over the campus Wi-Fi network via an MQTT broker. Each device runs the custom kernel module and management daemon, with the stock Minstrel-HT rate controller disabled and replaced by our policy-driven module. The IteRate agent currently uses OpenAI’s GPT-5.4 for all LLM inference, accessed via the LangGraph API.

Build and Deployment Pipeline

When the agent synthesizes a new eBPF rate control algorithm, the following pipeline executes autonomously: (1) Synthesis. The algorithm designer subagent writes eBPF C source, adhering to verifier constraints: compile-time loop unrolling (#pragma unroll), bounded stack allocation, pinned map references, and explicit bounds checks on all map-derived array indices. (2) Static Lint. A five-rule linter scans the source before compilation, catching the most common causes of verifier rejection: (1) array accesses indexed by map-loaded values without a preceding bounds check; (2) loops missing a #pragma unroll; (3) functions lacking __always_inline (required on kernels without BPFto-BPF call support); (4) excessive conditional nesting on map fields (threshold: 8 branches), which risks verifier state explosion; (5) stack-allocated structs exceeding the 512-byte BPF stack limit. The linter returns structured warnings with line numbers; the algorithm designer uses these to correct the source before compilation. (3) Cross-Compilation. The source is compiled targeting BPF EL at optimization level 2, using the target platform’s kernel headers to produce a relocatable ELF object. (4) OTA Deployment. The ELF binary is base64-encoded and transmitted over MQTT to the target device. The daemon idempotently initializes BPF maps (if not already pinned), loads the program via libbpf, and attaches it to the kernel module’s TX status hook or timer-based invocation path. (5) Verification Feedback. If the kernel verifier rejects the program, the verifier trace is returned to the agent. The algorithm designer diagnoses the failure (typically a missing bounds check or an unrolled loop exceeding the instruction budget) and generates a corrected version. (6) Activation. On successful load, the daemon switches the kernel module to BPF policy. The program begins executing on each TX completion, reading the stats map and writing rate decisions to the rate map.

Evaluation

We evaluate IteRate’s ability to evolve bitrate selection logic in real-time. We compare its performance against state-ofthe-art algorithms across diverse workloads and channel conditions, and analyze the computational overhead of the online AI agent. We allow the agent to converge to an algorithm for a maximum of 50 iterations of the loop. For all results, we report post-convergence A/B tests across 15 paired device samples, rotating between our algorithm and the baselines across multiple links for 2 minutes per sample. Workloads and QoE Metrics: We evaluate the system using 5 workloads that represent common wireless applications. Traffic is created by synthetically generating traffic patterns from a tool designed to use iperf to model application-layer traffic [36]. This allows us to systematically vary transmission patterns and load characteristics to produce controlled and reproducible traces. Each workload is paired with a distinct application-layer quality-of-experience (QoE) metric, reflecting the performance objective that matters to that application. (1) Peak Throughput. A single TCP flow runs without a bandwidth cap for 10 s, fully loading the wireless link. The QoE metric is receiver-side goodput (Mbps), which captures the maximum throughput achievable under sustained load. (2) File Download. We emulate bulk transfers using TCP bursts of 25 MB repeated three times. The QoE metric

The end-to-end latency from source code to in-kernel execution is under 10 seconds, dominated by cross-compilation. Source code and compiled ELF binaries are transmitted directly between the build system and edge devices without passing through the LLM context, preserving the agent’s context budget for reasoning. 9

Lynch et al.

Weighted Moving Average (EWMA) of packet success probabilities and dedicates 10% of traffic to random sampling to find the best throughput. (2) OpenEvolve [38]: A code-mutation evolutionary baseline that also interacts directly with the testbed to refine the bitrate algorithm. It executes an iterative process where the results of each testbed run are observed and used to evolve the bitrate algorithm over successive generations. We evaluate the best algorithm OpenEvolve is able to produce within a 1-hour window of evolution.

5.2

Figure 5: Radar plot comparing IteRate to OpenEvolve and Minstrel-HT across 5 workloads. Each axis corresponds to a different application workload and its associated QoE metric, with scores normalized so that higher values indicate better application-level performance. Across the five workloads, IteRate discovers four policies that outperform both OpenEvolve’s candidates and the Minstrel-HT baseline on their respective application metrics, illustrating the ability of IteRate to design good workload-specific algorithms rather than relying on a static rate-control policy. is average goodput across transfers, representing the effective download rate experienced by users during large file transfers. (3) Web Page Load. To approximate web browsing, we generate TCP bursts of 1,246 KB (the median web page size reported by HTTP Archive 2024). The QoE metric is mean flow completion time (FCT), which approximates the latency a user experiences when loading a page. (4) Voice over IP (VoIP). We emulate conversational voice traffic using a UDP stream sending G.711-sized packets (160 B every 20 ms) for 30 s. The QoE metric is Mean Opinion Score (MOS), computed from packet loss, jitter, and delay using a simplified ITU-T G.107 E-model. (5) Adaptive Video Streaming. We model video streaming using repeated TCP transfers of 1.8 MB segments representing a 3–4 s adaptive bitrate video chunk. The QoE metric is MOS derived from segment fetch time using an IQX-based exponential model.

5.1

Performance across applications

We plot the relative performance across five workloads for representative algorithms from three families: IteRate policies, OpenEvolve-generated policies, and the widely deployed Minstrel-HT baseline. Each axis corresponds to a distinct workload capturing a different application objective. Metrics are normalized per workload so that the bestperforming algorithm attains a score of 1.0, and others are scaled accordingly. The results reveal clear workload-dependent tradeoffs. For example, IteRate 3 (Appendix C) achieves the highest normalized peak throughput (1.00) and adaptive video QoE (1.00), while maintaining strong web performance (0.96). The IteRate 4 policy achieves the best VoIP quality (1.00) and strong file download throughput (0.85). In contrast, OpenEvolve-generated policies exhibit substantial imbalance: OpenEvolve 2 achieves moderate throughput (0.68) and VoIP quality (0.82), but performs poorly on latency-sensitive workloads such as web transfers (0.29) and adaptive video (0.00). The Minstrel baseline provides relatively balanced but consistently lower performance across workloads (e.g., 0.40 peak throughput and 0.44 video QoE). Overall, the IteRate policies span a larger area across the radar axes, indicating stronger performance across diverse workloads. This shows that by specializing rate selection to application objectives, IteRate consistently outperforms Minstrel-HT and OpenEvolve across scenarios.

5.3

Individual Workload Analysis

We present IteRate 1-4, OpenEvolve 1-2 and the Minstrel-HT baseline in terms of their performance on peak throughput, web flow completion time, and adaptive video performance. Figure 6a reports peak throughput under saturated traffic. IteRate 3 achieves the highest median throughput (9.1 Mbps), substantially exceeding both Minstrel (2.7 Mbps) and OpenEvolve policies (1.8–2.2 Mbps). Other IteRate variants maintain competitive performance while preserving stability across links. This indicates that the agent can synthesize rate policies that aggressively exploit high-quality links while avoiding unstable rate selections.

Baselines

We compare IteRate against two classes of bitrate selection algorithms to evaluate its performance across heuristic, statistical, and evolutionary paradigms: (1) Minstrel [46]: The industry-standard rate adaptation algorithm in the Linux kernel. It uses an Exponentially 10

IteRate : Autonomous AI Synthesis of In-Kernel eBPF Wi-Fi Rate Control Algorithms

(a) Peak Throughput

(b) Web Flow Completion Time

Figure 6: Individual comparisons of each algorithm on each specific workload. Across heterogeneous workloads, no single algorithm consistently dominates; instead, performance varies depending on the application characteristics. Our key advantage is that the agentic system can infer, from the observed workload, which algorithm is most appropriate for the current application. As the application executes, the agent continues to explore and evaluate policies under new workload conditions, enabling ongoing adaptation. Figure 6b compares web page flow completion time (FCT), where lower values are better. IteRate 1 and IteRate 3 achieve the lowest median FCT (1.7 s), outperforming both Minstrel (2.7 s) and OpenEvolve policies (4.5–5.0 s). This improvement highlights the importance of application-aware rate control: by prioritizing reliability and short bursts of traffic, IteRate significantly reduces web latency compared to generic throughput-oriented algorithms. Figure 6c shows the distribution of video MOS across algorithms. IteRate 3 achieves the highest median MOS (3.36, a score described as Excellent), outperforming both OpenEvolve policies and the Minstrel-HT baseline. IteRate 2 and IteRate 4 also maintain strong video quality with medians around 3.1–3.2, indicating that application-aware adaptation can sustain high streaming quality across varying link conditions. In contrast, OpenEvolve policies exhibit lower medians (2.64–3.13), while Minstrel provides moderate but less optimized performance (2.80). These results demonstrate that IteRate can explicitly optimize for latencysensitive real-time traffic.

“Piecewise-nonstationary BPF rate control with change detection will improve over soak time. . . local exploration around the current best arm. . . change-point detection resets.”

This proposal already shows a research idea that includes some form of temporal reasoning. The agent believed that the bitrate selection algorithm should behave differently after minutes of operation than in the initial seconds. The hypothesis was operationalized through an experiment configuration that extended the Minstrel baseline. However, the resulting experiments falsified the hypothesis. Under the application workload and another test the agent decided to run, the adaptive algorithm selected only MCS0. For R1, throughput dropped from 8.91 Mbps to 2.88 Mbps during the first trial, but after the agent decided to run a second trial, it observed that the performance dropped from 26.87 Mbps to 2.66 Mbps. Similar degradation occurred on R2. The agent summarized the result succinctly: the controller “collapses to MCS0 and does not improve over a long time.” Rather than adjusting parameters, the agent identified the mechanism of failure as catastrophic lock-in to the lowest rate. The next hypothesis explicitly targeted this failure mode, predicting that a successful design must “spend substantially less airtime at MCS0.”

Case Study: Agentic Protocol Evolution

To understand how IteRate discovers a working design, we analyze an example trajectory of its reasoning and experiments. Rather than behaving like a black-box optimizer, IteRate repeatedly proposes a hypothesis, executes an evaluation protocol, diagnoses the resulting failure mode, and refines the algorithm accordingly. In this experiment, the agent controls one sender and two receivers (R1 & R2).

Iterations 2–3: Verifier Constraints. The next two revisions introduced per-MCS EWMA statistics (similar to Minstrel) and deterministic retests to prevent lock-in. However, both implementations were rejected by the AP’s eBPF verifier:

Iteration 1: Change Detection Hypothesis. At the beginning of the problem, the Scientist tried to frame rate control as a non-stationary bandit problem. The agent proposed:

“Deployment/load verification failed with reg type unsupported for arg#0 function on_tx_status#42. . . appears to be a loader/verifier compatibility issue for this program shape.” 11

Lynch et al.

“Require repeated clean evidence before sustained promotion to MCS5 and retreat faster after retry inflation.”

This refinement produced the first across-the-board improvement. For R1, throughput increased from 3.77 Mbps to 9.98 Mbps in the early phase and from 6.40 Mbps to 7.82 Mbps during soak while reducing retry rates substantially. R2 also improved, reaching 21.57 Mbps and reducing UDP loss from 2.49% to 1.44%. Iterations 12–15: Weak-Link Hysteresis. Here the agent decided to test whether this approach would work across varied links. It changed the transmit power of the sender to 10 dBm, and observed that the algorithm struggled on very weak links. The agent diagnosed the new failure mode:

Figure 7: IteRate iterations over wall time. The agent explores successive versions (not necessarily monotonic improvements) until debugging/redeployment time exceeds a limit or progress stalls. It converges to a satisfactory algorithm in 75 minutes, even though its initial hypothesis already outperformed the naive baseline.

“The controller remains too willing to revisit MCS5 under persistent retry inflation.”

The solution introduced explicit hysteresis around MCS5: This discovery changed the search space. The agent inferred that only the callback and state “skeleton” of the previously accepted program could reliably pass verification. Instead of abandoning the design, the agent promoted this observation into a new rule: all subsequent algorithms must preserve the exact skeleton of the verified implementation.

MCS5 Cooldown Logic if current_mcs == MCS5 && (tx_failure || high_retry): mcs5_cooldown ← COOLDOWN if mcs5_cooldown > 0: current_mcs ← min(current_mcs, MCS4) if clean_successes ≥ 4: mcs5_cooldown ← 0

This modification improved degraded links under normal conditions, but did not fully recover near-outage links.

Iteration 4: Skeleton-Safe Anti-Collapse. Using the new constraint, the agent implemented a minimal modification that added a periodic retest and held values for longer. This version successfully eliminated collapse, but exposed a new limitation. Telemetry showed that nearly all transmissions used MCS4 (14847 of 14848 frames), producing lower throughput than the baseline. The algorithm had solved the collapse but became overly conservative. The agent concluded that the next design must maintain the anti-collapse property while enabling local upward motion in the rate ladder.

Iteration 27: Outage Guard. The final refinement targeted near-outage regimes explicitly. The new mechanism introduced an outage_guard that forces the controller to remain at MCS3 until a sequence of clean transmissions is observed: if failure_or_high_retry(mcs >= 4): last_good_mcs ← max(MCS3, current_mcs - 1) outage_guard ← GUARD_HOLD if outage_guard > 0: current_mcs ← max(MCS3, last_good_mcs) if clean_successes >= GUARD_EXIT: outage_guard ← 0

Iteration 7: Local Promotion and Demotion. The next revision introduced small local adjustments around the current rate, allowing promotion or demotion based on recent outcomes while preserving the anti-collapse safeguards. This design produced the first asymmetric result. For R1, throughput improved dramatically, increasing from 13.04 Mbps to 21.91 Mbps while reducing RTT from 87 ms to 60 ms. However, R2 regressed slightly from 13.61 Mbps to 10.38 Mbps. The agent described the outcome as “partially supported,” indicating that the mechanism worked for strong links but remained fragile for weaker ones.

The results here were promising, and the links retain the gains achieved in earlier iterations, producing IteRate Algorithm 3 above (Appendix C). This trajectory reveals a structured convergence process. The agent begins with a broad theoretical idea, falsifies it through experiments, discovers deployment constraints imposed by the verifier, and progressively refines the controller to address concrete failure modes. Each stage adds a new mechanism until the algorithm stabilizes across a range of link conditions. The agent repeatedly applies a simple reasoning loop: propose a mechanism, evaluate it under a fixed

Iteration 9: Conservative Promotion. To address this asymmetry, IteRate proposed a more conservative policy: 12

IteRate : Autonomous AI Synthesis of In-Kernel eBPF Wi-Fi Rate Control Algorithms

protocol, identify the failure mode, and redesign the controller to address that specific weakness.

[10] Youngkyu Choi and Sunghyun Choi. 2008. A joint design of admission control and transmission rate adaptation for VoIP over wireless network. In 2008 International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM). 1–12. https://doi.org/10.1109/ WOWMOM.2008.4594817 [11] Sayantan Choudhury and Jerry D. Gibson. 2007. Payload Length and Rate Adaptation for Multimedia Communications in Wireless LANs. IEEE Journal on Selected Areas in Communications 25, 4 (2007), 796–807. https://doi.org/10.1109/JSAC.2007.361909 [12] Cisco. 2026. Cisco Catalyst Center AI-Enhanced RRM Deployment Guide. https://www.cisco.com/c/en/us/td/docs/wireless/controller/ 9800/technical-reference/ai-enhanced-rrm-dg.html. (2026). accessed 2026-03-12. [13] Cisco Meraki. [n. d.]. Cisco Meraki Auto RF: Wi-Fi Channel and Power Management. https://documentation.meraki.com/MR/Radio_ Settings/Auto_RF%3A_Wi-Fi_Channel_and_Power_Management. ([n. d.]). accessed 2026-03-13. [14] Cisco Meraki. 2025. Meraki Health Overview. https: //documentation.meraki.com/Platform_Management/Dashboard_ Administration/Operate_and_Maintain/Monitoring_and_Reporting/ Meraki_Health_Overview. (2025). accessed 2026-03-12. [15] Extreme Networks. [n. d.]. Access Point System Reference Guide: Rate Selection Methods. https://documentation.extremenetworks. com/WiNG/7.3.1/APSRG/GUID-3D70DA57-4C08-4220-A19E3A95522CCA2C.shtml. ([n. d.]). WiNG 7.3.1 documentation; accessed 2026-03-12. [16] Varun Gupta, Craig Gutterman, Yigal Bejerano, and Gil Zussman. 2016. Experimental evaluation of large scale WiFi multicast rate control. In 35th Annual IEEE International Conference on Computer Communications (INFOCOM). IEEE, 1–9. https://doi.org/10.1109/INFOCOM.2016. 7524343 [17] P. Hamadanian, P. Karimi, A. Nasr-Enfahany, K. Noorbakhsh, J. Chandler, A. Parandeh, M. Alizadeh, and H. Balakrishnan. [n. d.]. Glia: A Human-Inspired AI for Automated Systems Design and Optimization. https://arxiv.org/abs/2510.27176. ([n. d.]). [18] Ivaylo Haratcherev, Jacco R. Taal, Koen Langendoen, Reginald L. Lagendijk, and Henk J. Sips. 2005. Automatic IEEE 802.11 rate control for streaming applications. Wireless Communications and Mobile Computing 5, 4 (2005), 421–437. https://doi.org/10.1002/wcm.301 [19] HPE Aruba Networking. [n. d.]. AirMatch and ClientMatch in ArubaOS 10. https://www.arubanetworks.com/techdocs/aos/wifidesign-deploy/security/multi-zone/airmatch-clientmatch/. ([n. d.]). accessed 2026-03-13. [20] HPE Aruba Networking. [n. d.]. How AI-Powered AirMatch Optimizes WLAN Performance. https://www.hpe.com/psnow/doc/ a00115435enw. ([n. d.]). accessed 2026-03-13. [21] Tingpei Huang, Shibao Li, and Shaoshu Gao. 2017. RaCA: A joint rate and channel adaptation scheme for dense 802.11n networks. Procedia Computer Science 111 (2017), 183–189. https://doi.org/10.1016/j.procs. 2017.06.026 [22] Glenn Judd, Xiaohui Wang, and Peter Steenkiste. 2008. Efficient Channel-Aware Rate Adaptation in Dynamic Environments. In Proceedings of the 6th International Conference on Mobile Systems, Applications, and Services (MobiSys). 118–130. https://doi.org/10.1145/1378600. 1378615 [23] Juniper Networks. [n. d.]. Overview of Juniper APs | Mist. https://www.juniper.net/documentation/us/en/software/mist/mistwireless/topics/concept/mist-wireless-guide-ap-overview.html. ([n. d.]). accessed 2026-03-12. [24] Juniper Networks. [n. d.]. RRM Overview | Mist. https: //www.juniper.net/documentation/us/en/software/mist/mistwireless/topics/topic-map/rrm.html. ([n. d.]). accessed 2026-03-13.

Conclusion

This paper presented IteRate, an autonomous research system to synthesize real-world Wi-Fi rate control algorithms. IteRate uses a multi-agent AI architecture to conduct the full scientific cycle: formulating hypotheses, writing eBPF programs that run inside the Linux kernel, deploying them overthe-air to Wi-Fi devices, collecting fine-grained telemetry for analysis, and iterating based on experimental evidence, all without human intervention. Performance on a 58-node testbed shows that its algorithms outperform Minstrel. More importantly, results show the agentic architecture can effectively automate research for non-trivial problems in wireless and networked systems.

References [1] Ali Abedi and Tim Brecht. 2014. T-RATE: A Framework for the TraceDriven Evaluation of 802.11 Rate Adaptation Algorithms. In Proceedings of the IEEE 22nd International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS). 1–10. [2] Ali Abedi, Andrew Heard, and Tim Brecht. 2016. T-SIMn: Towards the High Fidelity Trace-Based Simulation of 802.11n Networks. In Proceedings of the 19th ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM). 83–92. [3] Prashanth Aravinda Kumar Acharya, Ashish Sharma, Elizabeth M. Belding, Kevin C. Almeroth, and Konstantina Papagiannaki. 2010. Rate Adaptation in Congested Wireless Networks through Real-Time Measurements. IEEE Transactions on Mobile Computing 9, 11 (2010), 1535–1550. https://doi.org/10.1109/TMC.2010.108 [4] Abdullah Alomar, Pouya Hamadanian, Arash Nasr-Esfahany, Anish Agarwal, Mohammad Alizadeh, and Devavrat Shah. 2023. {CausalSim}: A causal framework for unbiased {Trace-Driven} simulation. In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23). 1115–1147. [5] Rauno Arike, Elizabeth Donoway, Henning Bartsch, and Marius Hobbhahn. 2025. Technical Report: Evaluating Goal Drift in Language Model Agents. (2025). arXiv:cs.AI/2505.02709 https://arxiv.org/abs/ 2505.02709 [6] John C. Bicket. 2005. Bit-Rate Selection in Wireless Networks. Master’s thesis. Massachusetts Institute of Technology. [7] Tony Braskich, Nattavut Smavatkul, and Steve Emeott. 2005. Optimization of a link adaptation algorithm for voice over wireless LAN applications. In IEEE Wireless Communications and Networking Conference (WCNC). 1602–1607. https://doi.org/10.1109/WCNC.2005.1424753 [8] Hye-Sung Byeon, Sunghyun Choi, and Saewoong Bahk. 2017. STRALE: Mobility-Aware Collaborative Rate Adaptation in Densely Deployed WLANs. In IEEE INFOCOM 2017. 1–9. https://doi.org/10.1109/ INFOCOM.2017.8057183 [9] Audrey Cheng, Shu Liu, Melissa Pan, Zhifei Li, Shubham Agarwal, Mert Cemri, Bowen Wang, Alexander Krentsel, Tian Xia, and Jongseok Park. 2025. Let the Barbarians In: How AI Can Accelerate Systems Performance Research. arXiv preprint arXiv:2512.14806 (2025). 13

Lynch et al.

on Computers and Communications (ISCC). [41] Ioannis Selinis, Konstantinos Katsaros, Seiamak Vahid, and Rahim Tafazolli. 2019. Damysus: A Practical IEEE 802.11ax BSS Color Aware Rate Control Algorithm. International Journal of Wireless Information Networks 26, 4 (2019), 285–307. https://doi.org/10.1007/S10776-01900439-6 [42] Prashiddha D Thapa, Arne Kappen, and Julius Schulz-Zander. 2024. Towards infrastructure-assisted wifi rate adaptation for converged networks with morpheus. In Proceedings of the 19th Workshop on Mobility in the Evolving Internet Architecture. 19–24. [43] Mythili Vutukuru, Hari Balakrishnan, and Kyle Jamieson. 2009. CrossLayer Wireless Bit Rate Adaptation. In Proceedings of the ACM SIGCOMM 2009 Conference on Data Communication. 3–14. [44] Starsky H. Y. Wong, Songwu Lu, Hao Yang, and Vaduvur Bharghavan. 2006. Robust Rate Adaptation for 802.11 Wireless Networks. In Proceedings of the 12th Annual International Conference on Mobile Computing and Networking (MobiCom). 146–157. [45] Dong Xia, Jonathan Hart, and Qiang Fu. 2013. Evaluation of the Minstrel Rate Adaptation Algorithm in IEEE 802.11g WLANs. In Proceedings of the IEEE International Conference on Communications (ICC). 2223–2228. [46] Dong Xia, Jonathan Hart, and Qiang Fu. 2013. Evaluation of the Minstrel Rate Adaptation Algorithm in IEEE 802.11g WLANs. In Proceedings of the IEEE International Conference on Communications (ICC). 2223–2228. [47] Yi Yang, Mahesh K. Marina, and Rajive L. Bagrodia. 2006. Experimental Evaluation of Application Performance with 802.11 PHY Rate Adaptation Mechanisms in Diverse Environments. In IEEE Wireless Communications and Networking Conference (WCNC). 2273–2278. https://doi.org/10.1109/WCNC.2006.1696649 [48] Hao Yin, Murali Ramanujam, Joe Schaefer, Stan Adermann, Srihari Narlanka, Perry Lea, Ravi Netravali, and Krishna Chintalapudi. 2024. ADR-X: ANN-Assisted Wireless Link Rate Adaptation for ComputeConstrained Embedded Gaming Devices. In 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24). Santa Clara, CA, 1331–1349.

[25] Juniper Networks. [n. d.]. Wi-Fi Data Rate Configuration | Mist. https://www.juniper.net/documentation/us/en/software/mist/ mist-wireless/topics/ref/mist-data-rates.html. ([n. d.]). accessed 202603-12. [26] Raja Karmakar, Samiran Chattopadhyay, and Sandip Chakraborty. 2017. SmartLA: Reinforcement Learning-Based Link Adaptation for High Throughput Wireless Access Networks. Computer Communications 110 (2017), 1–25. [27] Raja Karmakar, Samiran Chattopadhyay, and Sandip Chakraborty. 2020. An Online Learning Approach for Auto Link-Configuration in IEEE 802.11ac Wireless Networks. Computer Networks 181 (2020), 107426. [28] Malik Ahmad Yar Khan and Darryl Veitch. 2011. SmartRate: A new dynamic rate adaptation algorithm for 802.11 wireless networks. In 12th IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM). IEEE Computer Society, 1–10. https://doi.org/10.1109/WOWMOM.2011.5986389 [29] Shervin Khastoo, Tim Brecht, and Ali Abedi. 2020. NeuRA: Using Neural Networks to Improve WiFi Rate Adaptation. In Proceedings of the 23rd ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM). 161–170. [30] Jinseok Kim, Seongkwan Kim, Sunghyun Choi, and Daji Qiao. 2006. CARA: Collision-Aware Rate Adaptation for IEEE 802.11 WLANs. In IEEE INFOCOM 2006. 1–11. https://doi.org/10.1109/INFOCOM.2006.95 [31] Lefteris Kriara, Konstantinos Katsaros, George Xylomenos, and Ioannis Stavrakakis. 2015. SampleLite: Fast and Efficient Adaptive Rate Selection. In IFIP Networking Conference (IFIP Networking). 1–9. https: //doi.org/10.1109/IFIPNetworking.2015.7145308 [32] Mathieu Lacage, Mohammad Hossein Manshaei, and Thierry Turletti. 2004. IEEE 802.11 Rate Adaptation: A Practical Approach. In Proceedings of the 7th ACM International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM). 126–134. [33] Hyewon Lee, Seongho Byeon, Byoungjin Kim, Kwang Bok Lee, and Sunghyun Choi. 2014. Enhancing Voice over WLAN via Rate Adaptation and Retry Scheduling. IEEE Transactions on Mobile Computing 13, 12 (2014), 2791–2805. https://doi.org/10.1109/TMC.2013.54 [34] Chi-Yu Li, Chunyi Peng, Songwu Lu, Xinbing Wang, and Ranveer Chandra. 2015. Latency-aware rate adaptation in 802.11n home networks. In 2015 IEEE Conference on Computer Communications (INFOCOM). 1293–1301. https://doi.org/10.1109/INFOCOM.2015.7218505 [35] Wenxuan Liu, Chao Wang, Yaguang Zhang, Yao Liu, Chunyuan Zheng, and Zhiyong Feng. 2020. State-Aware Rate Adaptation for UAVs: A Deep Reinforcement Learning Approach. IEEE Transactions on Vehicular Technology 69, 10 (2020), 11697–11711. https://doi.org/10. 1109/TVT.2020.3017181 [36] MAMI Project. 2018. trafic: Traffic Mix Generator for Network Experiments. https://github.com/mami-project/trafic. (2018). GitHub repository. [37] Nguyen Le Minh, Choi Hee Yong, Choi Dongho, Kim Dongkyun, and Choi Choong Seon. 2011. RAMAS: Rate adaptation for Mobile users in 802.11n. In 2011 IEEE International Conference on Communications (ICC). 1–5. https://doi.org/10.1109/icc.2011.5963415 [38] OpenEvolve Authors. [n. d.]. OpenEvolve. https://github.com/ codelion/openevolve. ([n. d.]). GitHub repository; accessed 202603-13. [39] Ilias Pefkianakis, Sunghyun Yun, and Songwu Lu. 2016. MIRA: A MultiPath MIMO Rate Adaptation Algorithm for IEEE 802.11ac. IEEE/ACM Transactions on Networking 24, 6 (2016), 3635–3648. https://doi.org/10. 1109/TNET.2015.2504984 [40] Ruben Queirós, Eduardo Nuno Almeida, Helder Fontes, José Ruela, and Rui Campos. 2022. Wi-Fi Rate Adaptation using a Simple Deep Reinforcement Learning Approach. In Proceedings of the IEEE Symposium 14

IteRate : Autonomous AI Synthesis of In-Kernel eBPF Wi-Fi Rate Control Algorithms

A Bitrate Selection Agent — CLI Context A.1 Overview The bitrate-agent project is a DeepAgents workflow for developing and evaluating Wi-Fi bitrate selection (rate adaptation) algorithms on deployed hardware. The CLI agent has direct access to device control, experiment orchestration, ML training, and analysis tools through a persistent MQTT connection established at session startup. All tool calls share this connection; no subprocess or shell invocation is required for device interaction.

A.2

System Architecture

The agent operates with centralized orchestration over distributed Wi-Fi devices. Devices execute injected policies and stream telemetry, while all algorithm design, evaluation, and learning occur centrally.