DOCS demo
Support# Reference Simulation: Prioritizing Control Traffic During Bandwidth Saturation
**Bauxite Technical Demonstration Suite**
*June 2026*
---
```text
Reproducibility
Repository:
docs/demos/qos_swerve/
Environment:
Ubuntu 22.04
Kernel 5.15+
Loopback interface
Duration:
~20 seconds
Output:
MCAP recording
Latency charts
JSON raw telemetry
Objective:
Demonstrate kernel-level traffic classification and early packet discard
to prioritize critical control streams under bandwidth saturation.
```
---
## Abstract
Distributed robotic systems require low-latency control commands and timely navigation correction traffic. When connection bandwidth drops unexpectedly (e.g., from high-speed cellular to a constrained link), non-critical high-bandwidth telemetry, such as video feeds, can flood internal network queues and introduce latency in critical control loops. This paper details a reference simulation of **Bauxite's eBPF-based Quality of Service (QoS)** system, which implements kernel-level traffic classification and early packet discarding. We evaluate a simulated robotics workload consisting of navigation corrections, control traffic, telemetry, and video streams where network bandwidth is constrained to $1.5\text{ Mbps}$. Without Bauxite, critical control packets queue behind video data, resulting in elevated critical latency (averaging over 380 ms and peaking above 500 ms) and delayed navigation updates (exceeding 500 ms). With Bauxite's eBPF filters active, non-essential video frames are dropped early in the network processing path, maintaining critical control loop latency under 2 ms and correction update delay under 10 ms, ensuring stable and prioritized command delivery.
---
## 1. Introduction
Distributed robotic systems rely on low-latency control commands and timely navigation correction traffic. Edge nodes routinely transmit multiple classes of data, including high-definition camera feeds, over wireless links.
When connection quality degrades, available bandwidth can drop from tens of megabits to less than $2\text{ Mbps}$. Standard Linux network interfaces treat all queued packets equally at the driver level, causing bulk TCP/UDP video data to occupy system network queues. This starves and delays smaller, systems-critical UDP packets carrying navigation corrections and steering commands.
---
## 2. eBPF Traffic Shaping Architecture
Bauxite introduces a kernel-space traffic-shaping program using eBPF and XDP hooks. The system classifies network traffic into three priority classes based on destination port mappings:
1. **Critical**: Simulated navigation corrections (`port 7400`) and steering commands (`port 7401`).
2. **Telemetry**: Sensor data and system health diagnostics (`port 7410`).
3. **Bulk**: Video streaming (`port 8080`).
When a bandwidth bottleneck is detected, Bauxite triggers a drop mechanism on the Bulk lane. Rather than allowing the video stream to fill the system socket buffers and driver queues, Bauxite classifies and discards bulk traffic early in the network path, before it is enqueued into socket buffers. This gracefully degrades the video stream quality to maintain low latency on the Critical lane.
---
## 3. Methodology & Test Environment
The simulation environment is designed to evaluate Bauxite's traffic-shaping performance under synthetic network bottlenecks:
* **Host Setup**: Standard Linux testbed (Ubuntu 22.04 LTS, kernel 5.15).
* **Network Emulation**: A constrained virtual network link is configured over the loopback interface (`lo`) using Linux traffic control (`tc-netem`) to enforce a $1.5\text{ Mbps}$ bandwidth limit.
* **Workload Generator**: A custom simulator broadcasts a representative robotics workload:
* **Critical Lane**: Simulated navigation corrections (UDP, 20 Hz, port 7400) and steering commands (UDP, 50 Hz, port 7401).
* **Telemetry Lane**: Sensor data and system health diagnostics (UDP, 10 Hz, port 7410).
* **Bulk Lane**: H.264 video stream (TCP, ~3-4 Mbps, port 8080) that exceeds the throttled link capacity.
The simulation is evaluated across three sequential phases:
* **Phase 1: Standard Stack (Unmitigated Saturation)**: The link is throttled without Bauxite. Telemetry and video traffic queue ahead of control messages, causing latency spikes.
* **Phase 2: Bauxite Protected (Mitigated Saturation)**: Bauxite QoS is enabled under the same bottleneck. Video quality is reduced, but control traffic latency remains low.
* **Phase 3: Telemetry Replay & Audit**: The recorded MCAP telemetry is replayed and audited.
### Running the Demo
Execute the following to compile the simulator and run the workload sequence:
```bash
./docs/demos/qos_swerve/run.sh
```
This runs the simulation over the loopback interface, saving logs into `/tmp/bauxite_ag_sim/`.
### Foxglove Studio Visuals
Launch Foxglove Studio, open the generated `.mcap` recording, and import `docs/demos/qos_swerve/foxglove_layout.json` to view live telemetry signals, packet latencies, and QoS queue status.
---
## 4. Results and Performance Analysis
Telemetry data captured across 10 simulation trials is compiled in the table and chart below.
### QoS Traffic Shaping Performance Under Bandwidth Saturation (10-Trial Summary)
| Metric | Standard Linux Stack (Phase 1) | Bauxite Protected (Phase 2) |
| :--- | :---: | :---: |
| **Available Bandwidth** | 1.5 Mbps (Constrained) | 1.5 Mbps (Constrained) |
| **Critical Traffic Latency** | Elevated (Average $>380\text{ ms}$, Peaks $>500\text{ ms}$) | Low (Average $<1.5\text{ ms}$, Peaks $<2\text{ ms}$) |
| **Correction Update Delay** | Significantly delayed ($>500\text{ ms}$) | Near real-time ($<10\text{ ms}$) |
| **Bulk Traffic Throughput** | High (saturating queue) | Gracefully degraded (traffic shaped) |
| **Video Stream Quality** | Heavily buffered / frozen | Lowered resolution / framerate |
| **Bulk Traffic Discarded** | None (buffered until drop) | Bulk traffic was aggressively discarded |
### Control Loop Latency Under Network Congestion
Without Bauxite (Phase 1), the standard Linux stack buffers the heavy video stream, causing network queue build-up. Correction update delay grows to $>500\text{ ms}$ and critical control traffic latency peaks above $500\text{ ms}$. This latency delays safety-critical updates, resulting in simulated control loop degradation.
With Bauxite enabled (Phase 2), the eBPF filters intercept the Bulk packets and drop bulk traffic early in the network processing path. While video quality degrades, critical control messages continue to flow with a latency of just $1.24 \pm 0.31\text{ ms}$ and an update delay of $5.0 \pm 1.0\text{ ms}$, ensuring control traffic priority is maintained.
---
## 5. Conclusion
This simulation demonstrates that kernel-level traffic classification can preserve low-latency control traffic under severe bandwidth constraints by sacrificing non-essential bulk telemetry.
---
## Appendix: Raw QoS Telemetry and Control Latency Logs
The table below compiles checkpoint parameters and state validation stages recorded during the simulation run, aggregated across 10 trials:
| Time (s) | Standard Stack Latency (ms) | Bauxite Protected Latency (ms) |
| :---: | :---: | :---: |
| **0.0** | $<1.0\text{ ms}$ | $<1.0\text{ ms}$ |
| **2.0** | $<1.0\text{ ms}$ | $<1.0\text{ ms}$ |
| **4.0** | $<1.0\text{ ms}$ | $<1.0\text{ ms}$ |
| **5.0** | $416 \pm 138\text{ ms}$ | $1.3 \pm 0.3\text{ ms}$ |
| **6.0** | $523 \pm 128\text{ ms}$ | $1.2 \pm 0.2\text{ ms}$ |
| **8.0** | $518 \pm 69\text{ ms}$ | $1.0 \pm 0.2\text{ ms}$ |
| **10.0** | $513 \pm 161\text{ ms}$ | $1.2 \pm 0.3\text{ ms}$ |
| **12.0** | $487 \pm 159\text{ ms}$ | $1.2 \pm 0.3\text{ ms}$ |
| **14.0** | $562 \pm 95\text{ ms}$ | $1.4 \pm 0.3\text{ ms}$ |
| **16.0** | $505 \pm 161\text{ ms}$ | $1.0 \pm 0.3\text{ ms}$ |
| **20.0** | $415 \pm 154\text{ ms}$ | $1.2 \pm 0.3\text{ ms}$ |