PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Kaushalraj Puwar, B. Thangaraju

arXiv:2608.15380v2cs.NIcs.RO

TL;DR

DDS backpressure from a degraded subscriber can delay all readers sharing a RELIABLE writer, including safety-critical nodes. Adaptive Bridge separates critical and noncritical paths with independent writers and probe-based rate control, preserving 30 Hz throughput while reducing critical p95 latency to 1.55 ms across impairment levels.

  • Problem

    A network-impaired subscriber sharing a RELIABLE DDS writer can cause backpressure that degrades throughput and latency for other subscribers, including safety-critical nodes.

  • Method

    Adaptive Bridge uses a proxy with independent RELIABLE and BEST EFFORT writers, while a probe-based classifier applies hysteresis and adjusts noncritical forwarding rates.

  • Results

    Publisher throughput remains 30 Hz, while critical-subscriber p95 latency falls from 11.7–15.0 s to 1.55 ms across all impairment levels.

  • Takeaways & Limitations

    Topic splitting supplies the critical-latency benefit, while adaptive classification manages noncritical bandwidth without adding critical-path protection.

  • Takeaways & Limitations

    The proxy adds approximately 0.4 ms of latency, may bottleneck at high aggregate bandwidth, and its CPU and memory overhead were not independently measured.

Abstract

from arXiv · show

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.

I. INTRODUCTION

In ROS 2 systems using DDS, a degraded subscriber can block a shared RELIABLE writer, delaying healthy and safety-critical subscribers. Adaptive Bridge addresses this coupling with independent critical and noncritical writers plus adaptive rate control.

  • I. INTRODUCTION: A degraded RELIABLE subscriber can fill writer history, blocking new samples and degrading delivery for every subscriber sharing that writer.Packet loss, limited bandwidth, or CPU overload can leave samples unacknowledged until the writer history reaches capacity.
  • I. INTRODUCTION: Using BEST EFFORT for all subscribers removes coupling but sacrifices the delivery guarantees required by safety-critical local subscribers.Per-subscriber QoS settings do not alter the shared writer’s reliability policy.
  • I. INTRODUCTION: Adaptive Bridge splits traffic through independent DDS writers, using RELIABLE QoS for critical nodes and BEST EFFORT QoS for noncritical or degraded nodes.The proxy interrupts the backpressure chain at the application layer without changing DDS internals, RMW implementations, or the publisher node.
  • I. INTRODUCTION: The classifier uses active RTT probes and hysteresis to monitor subscriber health and adjust noncritical forwarding rates when impairment is detected.This provides adaptive rate management alongside structural topic splitting.
  • I. INTRODUCTION: The evaluation preserves publisher throughput at 30 Hz and reduces critical-subscriber p95 latency from up to 15 s to 1.55 ms across impairment levels.The reported baseline throughput collapse was 29–36%.

A. DDS QoS and Performance Characterization

Prior work characterizes DDS and ROS 2 coupling, latency, throughput variability, and lower-layer policy changes, but does not provide an application-layer mechanism for separating coupled subscriber paths. Adaptive Bridge introduces that separation through independent writers and per-subscriber health-based rate control.

  • A. DDS QoS and Performance Characterization: Prior analyses and measurements characterize DDS delivery, writer-history delay, ROS 2 execution effects, and throughput variability without proposing application-layer path separation.The cited related work stops at the coupling problem or addresses performance at lower layers.
  • A. DDS QoS and Performance Characterization: Publisher- or transport-level policy changes leave readers sharing one writer, so they do not remove shared reliability semantics or create independent subscriber paths.This limits the effectiveness of runtime DDS policy adjustment for subscriber-specific isolation.
  • A. DDS QoS and Performance Characterization: Adaptive Bridge applies mitigation at the ROS 2 application layer without changing DDS internals, RMW implementations, or publisher-side QoS reconfiguration.Its separation is implemented through writer structure rather than a shared-writer QoS profile.

III. SYSTEM DESIGN

Adaptive Bridge uses a proxy to receive an input topic and republish it through separate critical and noncritical DDS writers. This writer-level separation gives each reader group an independent queue, while runtime classification changes routing and rate limits without recreating publishers.

  • III. SYSTEM DESIGN: The proxy receives input topics and republishes them on independent critical and noncritical output topics, with a Policy Engine applying classifier-based limits and drop policies.Configuration Manager loads YAML settings at startup, and publishers are pre-created to avoid discovery churn and runtime races.
  • III. SYSTEM DESIGN: The critical writer uses RELIABLE QoS, while the noncritical writer uses BEST EFFORT QoS with separate reader matching and history queues.A slow BEST EFFORT reader therefore cannot backpressure the RELIABLE writer.
  • III. SYSTEM DESIGN: Writer splitting gives critical and noncritical reader groups independent queues, targeting the writer-history mechanism that dominates DDS delivery delay.The critical queue is determined by the number of critical readers.
  • III. SYSTEM DESIGN: Runtime classification changes routing decisions and rate limits inside the proxy without destroying or recreating publishers.This keeps the writer structure stable while forwarding behavior adapts.

C. Classifier – Subscriber Health Monitoring

The classifier estimates subscriber health from active probe RTT and loss measurements, then uses hysteretic states and policy rules to adjust noncritical forwarding. Its safety-biased defaults favor retaining critical treatment when classification is uncertain.

  • C. Classifier – Subscriber Health Monitoring: The classifier computes mean RTT and loss rate from 50 probe samples collected over a 10-second sliding window.Probes are sent at 5 Hz on a dedicated BEST EFFORT topic, and loss is the fraction receiving no response.
  • C. Classifier – Subscriber Health Monitoring: Subscribers occupy UNKNOWN, CRITICAL, or NONCRITICAL states, with CRITICAL receiving full-rate forwarding and NONCRITICAL receiving rate-limited forwarding.UNKNOWN is treated as CRITICAL when allow_unknown_state is false.
  • C. Classifier – Subscriber Health Monitoring: Hysteresis requires three consecutive evaluations: demotion occurs above 50 ms RTT or 1.5% loss, while promotion requires below 35 ms RTT and 0.5% loss.Manual YAML overrides take precedence over probe data, and intermediate readings leave the state unchanged.
  • C. Classifier – Subscriber Health Monitoring: The safety bias treats a critical-as-noncritical error as potentially dropping safety-critical messages, whereas the reverse error primarily wastes bandwidth.This rationale informs the defaults and UNKNOWN handling.
  • C. Classifier – Subscriber Health Monitoring: In NORMAL mode, critical subscribers receive the publisher’s native rate while the noncritical path forwards at 10 Hz; degraded subscribers are limited to 3 Hz.The policy engine selects forwarding behavior from classifier state.
  • C. Classifier – Subscriber Health Monitoring: Critical forwarding is always performed first, while noncritical forwarding may be queued, throttled, or dropped without blocking critical delivery.Bounded queues and stale-drop policies further constrain the noncritical path.

E. Safety Supervisor

The safety supervisor monitors proxy health and escalates through DEGRADED and EMERGENCY modes to protect critical-path delivery. The evaluation also tests whether adaptive classification adds benefit beyond static topic splitting.

  • E. Safety Supervisor: The supervisor preserves the critical path by suspending noncritical forwarding when overload approaches and stopping all forwarding only under extreme failure.It tracks queue occupancy, callback lag, and error counts, publishing diagnostics in EMERGENCY mode.
  • E. Safety Supervisor: The evaluation compares baseline behavior, proxy topic splitting, and adaptive classification under bursty wireless loss.The hypotheses test DDS backpressure, critical-subscriber protection, and any additional benefit from adaptation over static splitting.
  • E. Safety Supervisor: Adaptive classification manages the noncritical path, while topic splitting supplies the critical-path protection.

B. Testbed Setup

The testbed uses Docker containers to publish and proxy laser scans while selectively impairing only the slow subscriber path with controlled Gilbert-Elliott loss. Experiments vary impairment duration and severity in a reproducible network setup.

  • B. Testbed Setup: The testbed routes 30 Hz LaserScan traffic through a proxy, with the critical subscriber on the LAN and the slow subscriber representing an impaired remote node.The slow subscriber runs a probe responder for bridge experiments.
  • B. Testbed Setup: The setup uses four Docker containers connected by a bridge network.
  • B. Testbed Setup: Gilbert-Elliott impairment affects only the slow-subscriber path, while the critical path remains pristine and probe responses receive asymmetric return-path delay.The return-path impairment is 20 ± 10 ms.
  • B. Testbed Setup: Docker bridge networking and publisher-egress filtering expose the slow subscriber to controlled loss without applying impairment to other destinations.
  • B. Testbed Setup: Experiments run for 180 s under impairment, 120 s when clean, and 240 s for toggled impairment scenarios.

D. Scenarios and Metrics

The evaluation measures latency, throughput, variability, noncritical delivery, and classifier transitions across baseline, adaptive-bridge, and ablation experiments. Baseline impairment produces the expected throughput collapse and extreme critical-subscriber tail latency.

  • D. Scenarios and Metrics: The ten experiments include four baseline runs, five classifier-enabled bridge runs, and one bridge ablation with classification disabled.
  • D. Scenarios and Metrics: The evaluation records critical latency at p50 and p95, publisher throughput and variability, noncritical latency, and classifier transition count.The cross-RMW comparison additionally reports p99 latency.
  • D. Scenarios and Metrics: Latency is measured as receive time minus the ROS message header timestamp, while publisher rate counts publication attempts in 5-second windows.Rate standard deviation is computed over 5-second sliding windows to capture burst-driven instability.
  • D. Scenarios and Metrics: Under impairment without a bridge, throughput falls to 19.2–21.4 Hz and critical-subscriber p95 latency reaches 11.7–15.0 s.The 29–36% throughput drop and 8.5–8.7 Hz rate standard deviation indicate burst-driven instability.
  • D. Scenarios and Metrics: Median latency remains near 1 ms during baseline impairment because backpressure appears primarily in tail latency and throughput.Messages queue little before the 200-sample pool cap is reached.

B. Bridge: Eliminating the Coupling (H2)

Adaptive Bridge preserves publisher throughput and sharply reduces critical-subscriber tail latency by separating critical and noncritical subscribers onto independent DDS writers. Hysteresis limits classifier transitions, while the critical-path benefit comes from topic splitting rather than adaptation.

  • B. Bridge: Eliminating the Coupling (H2): Critical-subscriber p95 latency stays at or below 1.57 ms across bridge runs, compared with 15.0 s in the baseline, while publisher throughput remains 30.0 Hz.The reported 5 s windowed publisher-rate standard deviation is 0.0 Hz at one-decimal resolution.
  • B. Bridge: Eliminating the Coupling (H2): Impaired runs show one sustained demotion after stabilization, while hysteresis prevents further classifier changes.The clean run shows five startup and probe-settling transitions that affect only noncritical rate control.
  • B. Bridge: Eliminating the Coupling (H2): Under strong impairment, throughput rises from 19.2 Hz to 30.0 Hz and critical p95 latency falls from 15,043 ms to 1.55 ms.The reduction is approximately a factor of 9,700.
  • B. Bridge: Eliminating the Coupling (H2): In clean mode, the bridge adds approximately 0.4 ms, increasing p50 latency from 0.65 ms to 1.07 ms.
  • B. Bridge: Eliminating the Coupling (H2): Independent DDS writers eliminate the backpressure coupling between slow and critical subscribers.

C. Cross-RMW Validation

Across Fast DDS and Cyclone DDS, Adaptive Bridge preserves critical-path performance under identical bursty-loss impairments despite different publish semantics.

  • C. Cross-RMW Validation: The evaluation repeats the bridge scenarios with Cyclone DDS under identical Gilbert-Elliott conditions and switches RMWs without code changes.The harness uses the --rmw flag for the cross-RMW comparison.
  • C. Cross-RMW Validation: Critical subscriber p99 latency stays below 2 ms and publisher throughput remains 30.0 Hz across all impairment levels for both RMWs.Table IV reports equivalent bridge protection across Fast DDS and Cyclone DDS.
  • C. Cross-RMW Validation: Fast DDS baseline critical p99 latency reaches 14,000–17,000 ms when its writer pool fills and publish() returns errors.Messages accumulate as backlog while the timer continues firing.
  • C. Cross-RMW Validation: Cyclone DDS blocks dds_write() when its history cache fills, preventing further message creation and backlog formation.Its critical p99 latency remains near the low-latency range described in the comparison.

E. Ablation: Topic Splitting vs. Classification (H3)

The ablation separates the roles of topic splitting and classification: splitting protects critical latency, while classification reduces noncritical bandwidth during impairment.

  • E. Ablation: Topic Splitting vs. Classification (H3): Critical latency is nearly identical with and without classification: p95 is 1.55 ms for bridge moderate versus 1.57 ms in the ablation.The ablation also reports p50 values of 1.10 ms and 1.09 ms, respectively.
  • E. Ablation: Topic Splitting vs. Classification (H3): Disabling classification leaves noncritical traffic at 10 Hz, whereas enabled classification reduces it to 3 Hz during degraded periods.On bandwidth-constrained Wi-Fi, this reduction saves approximately 70% of noncritical bandwidth and reduces proxy load and contention.
  • E. Ablation: Topic Splitting vs. Classification (H3): H3 is partially confirmed: classification adds adaptive noncritical bandwidth control but does not improve critical-path protection beyond static topic splitting.In the toggle experiment, detection and recovery occur within approximately 20 s after impairment changes.
  • E. Ablation: Topic Splitting vs. Classification (H3): The bridge adds approximately 0.4 ms of latency, while proxy CPU and memory overhead are not independently measured.The authors identify possible high-bandwidth proxy bottlenecks and leave those overheads for future evaluation.
  • E. Ablation: Topic Splitting vs. Classification (H3): The evaluation remains bounded by reactive classification, two evaluated RMWs, controlled loss parameters, and a single proxy process.Intermittent impairments, additional RMWs or message types, real-world Wi-Fi traces, and process-level redundancy remain outside the demonstrated scope.

VII. CONCLUSION

Adaptive Bridge isolates critical and noncritical ROS 2 subscribers through application-layer topic splitting, preserving publisher throughput and sharply reducing critical-subscriber tail latency across evaluated impairments. Its deployment requires no changes to DDS internals, RMW implementations, or the publisher node, while cross-RMW evaluation showed comparable protection under the tested conditions.

  • 11.7–15.0 s to 1.55 ms: critical-subscriber p95 latency fell across all impairment levels while the publisher maintained 30 Hz instead of the baseline 29–36% collapse.The reported result attributes the critical-latency benefit to topic splitting.
  • Adaptive Bridge separates critical and noncritical paths with independent DDS writers, eliminating backpressure coupling in mixed-criticality ROS 2 deployments.The approach operates at the ROS 2 application layer without modifying DDS internals, RMW implementations, or the publisher node.
  • The adaptive classifier manages bandwidth on the noncritical path but provides no additional critical-path protection beyond topic splitting.
  • Fast DDS and Cyclone DDS showed comparable critical-path protection under the evaluated impairments.
  • Future work includes multi-proxy redundancy, additional RMW evaluations, and validation on real-robot deployments.
Loading 2608.15380v2…