Adaptive Bridge: A Proxy-Based Decoupling Layer for Mitigating DDS Backpressure in ROS 2

AI summary

Overview

Research area: Networked robotics middleware — specifically ROS 2 / DDS quality-of-service behaviour under network impairment (cs.NI).

Technical level: Advanced. The paper assumes familiarity with DDS reliability semantics (RELIABLE vs. BEST_EFFORT writers, writer history, acknowledgements), ROS 2 RMW implementations, and Linux tc netem traffic shaping.

Scope: A single paper presenting a proxy-based decoupling layer that isolates critical ROS 2 subscribers from backpressure caused by impaired noncritical subscribers, evaluated on a Docker testbed under a Gilbert-Elliott bursty loss model.

What This Paper Is About

In ROS 2 systems using DDS, samples on a RELIABLE topic stay in the writer's history until every matched reader acknowledges them. If one subscriber is slow — packet loss, limited bandwidth, or CPU overload — unacknowledged samples accumulate until the writer history fills, at which point the publisher can no longer write new samples. The result is that a single degraded subscriber degrades throughput and latency for every subscriber sharing that publisher, including local safety-critical ones. The paper's goal is to break this coupling at the ROS 2 application layer without touching DDS internals, RMW implementations, or the publisher node.

Key Contributions

1. A proxy-based architecture for subscriber decoupling in ROS 2 that structurally isolates critical and noncritical data paths by republishing through two independent DDS writers — a RELIABLE writer for critical nodes and a BEST_EFFORT writer for noncritical or degraded ones.

2. An active-probe classifier with hysteresis for adaptive rate management on the noncritical path, using RTT and loss thresholds with three-consecutive-evaluation confirmation to prevent oscillation, plus a documented safety bias toward treating unknown subscribers as critical.

3. A reproducible evaluation methodology combining the Gilbert-Elliott bursty loss model with a Docker-based testbed that applies per-subscriber network impairment via tc netem, with version-controlled configurations and released orchestration and analysis scripts.

4. Quantitative demonstration that publisher throughput is preserved at 30 Hz (against a 29–36% collapse in the unmitigated baseline) and that critical subscriber tail latency is reduced from up to 15 s to 1.55 ms at p95 across all impairment levels, reproduced across two RMW implementations.

Main Findings

• Baseline coupling confirmed (H1). With no bridge and under impairment, publisher throughput collapsed to 19.2–21.4 Hz — a 29–36% drop from the configured 30 Hz — while critical-subscriber p95 latency reached 15,013 ms, 11,666 ms, and 15,043 ms for the mild, moderate, and strong scenarios respectively. Median latency stayed near 1 ms (0.65 ms clean, 0.97–1.02 ms impaired), so backpressure appeared mainly in tail latency and throughput. Rate standard deviation of 8.5–8.7 Hz in impaired runs indicated burst-driven instability, consistent with the 200-sample writer pool filling and draining erratically.

• Topic splitting eliminates the coupling (H2). With the bridge enabled, publisher throughput stayed at 30.0 Hz in every scenario, with 5-second windowed rate standard deviation of 0.0 Hz at the reported one-decimal resolution. Critical-subscriber p95 latency never exceeded 1.57 ms across bridge runs. The clean baseline p50 of 0.65 ms rose to 1.07 ms with the bridge, implying roughly 0.4 ms of added proxy hop latency.

• The strongest contrast. Under strong impairment, publisher throughput rose from 19.2 Hz to 30.0 Hz and critical p95 latency fell from 15,043 ms to 1.55 ms — a factor of approximately 9,700.

• Classifier behaviour. Impaired bridge runs produced only two classifier transitions each: a single demotion to NONCRITICAL after initial stabilization, with hysteresis preventing further changes. The clean bridge run still showed five transitions during startup and probe settling despite no network impairment — these affected only noncritical rate control, not the critical path. The toggle experiment, which alternated impairment at 60-second intervals over 240 s, produced 9 synchronized transitions, with detection and recovery within approximately 20 s.

• Ablation: the classifier does not improve the critical path (H3, partially confirmed). With the topic split but the classifier disabled, critical latency was p50 = 1.09 ms and p95 = 1.57 ms, versus p50 = 1.10 ms and p95 = 1.55 ms for bridge_moderate — nearly identical. What the classifier changes is the noncritical path: with it disabled, noncritical traffic continues at 10 Hz during impairment; with it enabled, the rate drops to 3 Hz during degraded periods, saving approximately 70% of noncritical bandwidth on a constrained Wi-Fi link and reducing proxy load and contention.

• Cross-RMW portability. Repeating the matrix with Cyclone DDS (rmw_cyclonedds_cpp) under identical Gilbert-Elliott conditions kept critical p99 latency below 2 ms and throughput at 30.0 Hz for both RMWs in all four bridge scenarios. The two implementations handle publish() differently under backpressure: Fast DDS uses non-blocking publish(), so once the max_samples=200 pool fills the call returns an error while the timer keeps firing, messages accumulate as a backlog, and baseline critical p99 reaches 14,000–17,000 ms. Cyclone DDS uses blocking publish(); when its 600 KiB writer history cache fills, dds_write() blocks and prevents further message creation, so no backlog forms and critical p99 stays near 1 ms even under impairment.

• Distribution shape (Fig. 5). In the baseline CDF panel, clean latency is below 1 ms while impaired tails exceed 18 s. In the bridge panel, all four impairment CDFs overlap near 1–2 ms, showing no observable effect of impairment on critical-path delivery.

• Proxy overhead is small but unmeasured beyond latency. The bridge adds approximately 0.4 ms. CPU and memory overhead of the proxy were not independently measured.

Methodology in Plain English

The researchers inserted a middleman process — the Adaptive Bridge proxy — between the publisher and its subscribers. The proxy subscribes to the original topic and forwards each message through two separate DDS output writers that keep their own history queues and acknowledgement schedules: a RELIABLE one for critical subscribers and a BEST_EFFORT one for noncritical or degraded subscribers. Because a slow reader on the BEST_EFFORT writer cannot hold up the RELIABLE writer, the backpressure chain is broken at the DDS endpoint level.

The proxy also probes subscriber health. Probe messages carrying a sequence number are sent at 5 Hz on a dedicated BEST_EFFORT topic; a responder at the subscriber returns the sequence number and timestamps. Over a sliding window of 50 samples (10 s), the classifier computes mean RTT and loss rate (the fraction of probes receiving no response). A per-subscriber state machine moves a subscriber from CRITICAL to NONCRITICAL when RTT exceeds 50 ms or loss exceeds 1.5% for three consecutive evaluations, and back to CRITICAL only when RTT falls below 35 ms and loss below 0.5% over the same number of evaluations. Readings between the two thresholds leave the state unchanged. A YAML manual override forces a state regardless of probe data, and UNKNOWN subscribers are treated as CRITICAL when allow_unknown_state is false. A Policy Engine translates these states into forwarding behaviour: in NORMAL mode the noncritical path forwards at a configured 10 Hz; in DEGRADED mode a token-bucket limiter caps the noncritical BEST_EFFORT writer at 3 Hz. Messages older than 200 ms (configurable) are dropped before forwarding, all internal proxy queues are bounded, and critical forwarding always runs first and is never blocked by noncritical work. A separate Safety Supervisor watches queue occupancy, callback processing lag, and error counts; it suspends noncritical forwarding entirely in DEGRADED mode and stops all forwarding with diagnostics in EMERGENCY mode.

For evaluation, four Docker containers ran on a bridge network: one publishing sensor_msgs/LaserScan at 30 Hz, one holding the proxy in bridge experiments, a critical subscriber on the LAN, and a slow remote-style subscriber with a probe responder. Fast DDS XML profiles disabled shared memory and specified only the UDPv4 transport so that DDS traffic crossed the container network interface and was visible to tc; the writer resource limit was set to max_samples=200 to reproduce bounded-pool behaviour. Linux tc netem applied a Gilbert-Elliott two-state Markov loss model to the slow subscriber's path only, leaving the critical path pristine, with an asymmetric return-path impairment of 20 ± 10 ms on probe responses. Four impairment levels were used: Clean (0% average loss), Mild (p = 1%, r = 15%, 0.5% good-state loss, 30% bad-state loss, 2.3% average), Moderate (p = 3%, r = 15%, 0.5% good, 40% bad, 7.1% average), and Strong (p = 2%, r = 10%, 1.0% good, 50% bad, 9.2% average). Impaired runs lasted 180 s and the clean run 120 s, with up to approximately 5,400 latency samples at 30 Hz per run; the toggle experiment ran 240 s with impairment alternating at 60 s intervals. Ten experiments were run in total: four baseline runs without the bridge (one per impairment level), five with the bridge and classifier enabled, and one ablation with the bridge present but the classifier disabled. Latency was computed as receive time minus the ROS message header timestamp using the ROS epoch clock; publisher rate was computed from publication attempts per 5-second window, with rate standard deviation over 5-second sliding windows.

Why This Matters

Impact on research. The paper reframes the slow-subscriber backpressure problem as a structural issue — writer-queue sharing — rather than a QoS-policy tuning problem, and shows that the fix can live at the application layer. It also contributes a cross-RMW observation that the two popular ROS 2 middlewares manifest the same backpressure differently (Fast DDS as an undelivered-message backlog, Cyclone DDS as reduced message generation), which is a distinction existing ROS 2 backpressure analyses do not draw.

Real-world applications.

• Mobile robots that publish sensor data (the paper's example is LaserScan at 30 Hz) to a remote visualization node over Wi-Fi while local collision avoidance must keep receiving fresh data.
• Mixed-criticality robot deployments where local control loops and remote monitoring share one publisher and one wireless link.
• Bandwidth-constrained teleoperation and remote inspection, where the adaptive noncritical rate control lets operators trade visualization fidelity for link survival.
• Multi-robot or fleet scenarios where many subscribers attach to a single source and one degraded node would otherwise stall the whole pipeline.

Industry relevance. The approach requires no changes to DDS internals, RMW implementations, or the publisher node, and the authors state the implementation is released publicly, with the ROS 2 package indexed for the Jazzy distribution in the ROS Index. That lowers the adoption barrier for teams with existing ROS 2 stacks who cannot modify middleware or vendor code, and it offers a mitigation option where changing to BEST_EFFORT globally would sacrifice the delivery guarantees safety-critical local nodes depend on.

Future Directions

• Measuring and bounding proxy overhead. CPU and memory cost of the proxy was not independently measured. The authors flag that a proxy may become a bottleneck at high aggregate bandwidth, so resource characterisation and scaling tests are open.
• Predictive rather than reactive classification. The current classifier detects sustained impairments in roughly 20 s from a 50-sample window, so intermittent impairment shorter than that window may not trigger a state change. Trend-based predictive classification remains future work.
• Broader RMW and message-type coverage. Only Fast DDS and Cyclone DDS were evaluated under identical impairment; other RMWs such as RTI Connext, and larger message types such as PointCloud2, remain to be tested.
• Real-network validation and redundancy. The Gilbert-Elliott parameters are deliberately controlled and are not claimed to replicate any specific real-world Wi-Fi deployment, so validation against empirically measured Wi-Fi traces is identified as future work. The proxy process also remains a single point of failure, motivating an external watchdog or redundant proxy configuration and real-robot deployment validation.

Target Audience

Robotics and middleware engineers working on ROS 2 systems with mixed-criticality subscriber sets, particularly those deploying over wireless links where one degraded node can stall a publisher. It also suits researchers studying DDS QoS behaviour, real-time publish-subscribe performance, or ROS 2 middleware adaptation, and practitioners who need a deployable mitigation that does not require modifying DDS internals, RMW implementations, or publisher code. Readers without prior exposure to DDS writer semantics will need background reading on RELIABLE/BEST_EFFORT reliability and writer history to follow the mechanism.

Authors’ abstract

In systems built on Robot Operating System 2 (ROS 2) and using Data Distribution Service (DDS), a single network-impaired or throttled subscriber on a RELIABLE topic can cause backpressure that degrades throughput and latency for all other subscribers, including safety-critical ones sharing the publisher, because the publisher's DDS writer can no longer accept new samples. We present Adaptive Bridge, a proxy-based layer that decouples critical subscribers from degraded or noncritical ones, thereby isolating the critical path through topic splitting and dynamic rate control. The proxy acts as a middleman and subscribes to the original topic and republishes the messages to two independent DDS writers: one RELIABLE writer for critical nodes and one BEST EFFORT writer for noncritical or degraded nodes, thus isolating the degraded nodes and safeguarding the publisher and critical nodes from backpressure. A probe-based classifier actively monitors subscriber health through sampling with hysteresis and adjusts subscriber rate limits in real time. We evaluate the system under a Gilbert-Elliott bursty wireless loss model using a reproducible Docker-based harness. The results show that using the Adaptive Bridge in our evaluation harness reduces the critical subscriber tail p95 latency from up to 15 s to 1.55 ms across all impairment severities while preserving the publisher's configured throughput.