DDS QoS Practical Guide

Quality of Service (QoS) policies in the Data Distribution Service (DDS) standard allow you to tune reliability, memory consumption, latency, and fault tolerance per topic and per entity without touching application code.

DDS does not use a single blanket transport configuration. Instead, it enforces a Request vs. Offered (RxO) contract: a DataWriter offers a QoS level, and a DataReader requests one. If the subscriber requests a stricter guarantee than the publisher offers (for example, requesting RELIABLE communication from a BEST_EFFORT writer), the DDS middleware refuses the connection and reports an incompatible QoS error.

Below is a practical, problem-driven guide mapping common engineering challenges to standard DDS QoS policies.

Quick Reference: Problem to QoS Mapping

1. Buffering & History Management

The Problem

You need to store a history of samples per instance—either a fixed sliding window (e.g., the last 10 telemetry readings for trend calculation) or every event until the application processes it.

Standard QoS Policies

• HISTORY:
  • KEEP_LAST(depth): Keeps only the most recent N samples per instance. When a new sample arrives and the cache is full, the oldest unread sample for that instance is discarded.
  • KEEP_ALL: Retains all samples for each instance until the application reads or takes them.
• RESOURCE_LIMITS:
  • max_samples: Total samples the entity can hold across all instances.
  • max_instances: Total distinct data keys the entity can track.
  • max_samples_per_instance: Maximum samples held for any single key instance.

Trade-offs & Pitfalls

• Unbounded Memory Exhaustion: Setting HISTORY to KEEP_ALL without configuring finite RESOURCE_LIMITS is dangerous. If a subscriber falls behind or network congestion builds up, the middleware will continuously allocate memory on the heap until the process crashes.
• Instance vs. Global Limits: max_samples_per_instance multiplied by max_instances must be greater than or equal to max_samples. Misconfiguring these bounds causes sample rejections even when total heap space is available.

2. Active-Standby Redundancy & Failover

The Problem

You have redundant nodes (e.g., a primary flight controller and a standby backup) publishing to the same topic. You want all subscribers to consume commands exclusively from the primary node. If the primary crashes, subscribers must seamlessly cut over to the backup without manual reconfiguration.

Standard QoS Policies

• OWNERSHIP:
  • SHARED: Multiple DataWriters can update the same instance simultaneously. All subscribers receive samples from all writers.
  • EXCLUSIVE: Only the DataWriter with the highest ownership strength is permitted to update a given data instance.
• OWNERSHIP_STRENGTH:
  • An integer value (e.g., Primary = 100, Standby = 50) assigned to a DataWriter.
• LIVELINESS:
  • Configures heartbeat leases so subscribers know when the primary writer is dead.

Trade-offs & Pitfalls

• RxO Compatibility: OWNERSHIP is a strict Request vs. Offered policy. If the DataWriter offers SHARED and the DataReader requests EXCLUSIVE, they will not match.
• Standby Network Traffic: In basic setups, standby writers still transmit samples over the network; the subscriber’s DDS layer discards them until the primary’s liveliness expires. Combine with LIVELINESS policies to tune failover detection latency versus heartbeat network overhead.

3. Late-Joiner State Synchronization

The Problem

A node starts after the system is already running (e.g., a diagnostic GUI connected midway through an operation, or a restarted service). The new node needs the current configuration, calibration parameters, or static map without having to send a request-response query.

Standard QoS Policies

• DURABILITY:
  • VOLATILE: No historical samples are retained. Late joiners only receive samples published after connection.
  • TRANSIENT_LOCAL: The DataWriter retains historical samples in its local memory. When a matching late-joining DataReader appears, the writer automatically transmits its cached history.
  • TRANSIENT: Samples persist in middleware memory beyond the lifetime of the DataWriter process.
  • PERSISTENT: Samples are saved to permanent storage (disk) and survive system reboots.
• RELIABILITY:
  • Must be set to RELIABLE.

Trade-offs & Pitfalls

• Must Pair with Reliable: TRANSIENT_LOCAL durability requires RELIABLE communication. Configuring TRANSIENT_LOCAL with BEST_EFFORT is invalid in DDS and will not deliver historical state to late joiners.
• History Depth Coupling: A TRANSIENT_LOCAL writer only sends up to the depth configured in its HISTORY QoS. If you need late joiners to receive only the current active state, configure DURABILITY: TRANSIENT_LOCAL with HISTORY: KEEP_LAST(1).

4. High-Rate Telemetry & Low-Latency Sensor Streams

The Problem

Sensors like LiDARs, cameras, and IMUs produce data at high frequencies (50–1000 Hz). Missing an occasional frame is acceptable, but waiting for retransmissions causes head-of-line blocking and introduces latency spikes into real-time pipelines.

Standard QoS Policies

• RELIABILITY:
  • BEST_EFFORT: Packets are transmitted without acknowledgments or retransmissions. Missing packets are dropped.
• HISTORY:
  • KEEP_LAST(1): The reader and writer caches only hold the latest reading. Older samples are overwritten immediately.

Trade-offs & Pitfalls

• Zero Retransmission Overhead: BEST_EFFORT consumes minimal bandwidth and avoids ACK/NACK storms on lossy wireless or multi-subscriber networks.
• No Gap Detection: The receiving application must be designed to tolerate occasional missing sequence numbers.

5. Mission-Critical Commands & State Changes

The Problem

Discrete commands—such as emergency stop triggers, arming instructions, state-machine transitions, or configuration updates—must never be dropped or silently lost under network congestion.

Standard QoS Policies

• RELIABILITY:
  • RELIABLE: The DataWriter requires acknowledgments (ACKs) from DataReaders and automatically retransmits lost packets.
• HISTORY:
  • KEEP_LAST(N) (or KEEP_ALL with strict RESOURCE_LIMITS).

Trade-offs & Pitfalls

• Writer Blocking & Backpressure: When a reliable writer’s queue fills because a slow reader is failing to acknowledge samples, the writer will either block on write() or return a timeout error, depending on the RELIABILITY.max_blocking_time setting.
• Increased Jitter: Retransmissions use network bandwidth and introduce latency variability under packet-loss conditions.

6. Publisher Watchdogs & Control Loop Monitoring

The Problem

A real-time control loop expects sensor readings or heartbeat signals at a strict periodic rate (e.g., every 20 ms / 50 Hz). If a publisher hangs, crashes, or misses its deadline, the system must trigger an immediate safety alarm or enter a safe state.

Standard QoS Policies

• DEADLINE:
  • Sets the maximum expected period between consecutive samples for each data instance.
  • DataWriter offers: “I will publish at least once every period T_offer.”
  • DataReader requests: “Notify me if I do not receive a sample within period T_req.”
• LIVELINESS:
  • AUTOMATIC: Middleware automatically sends heartbeats as long as the participant process is alive.
  • MANUAL_BY_TOPIC: The application must actively write a sample or assert liveliness on the topic within the lease_duration.

Trade-offs & Pitfalls

• RxO Constraint: The DataWriter’s offered deadline must be less than or equal to the DataReader’s requested deadline ($T_{\text{offer}} \le T_{\text{req}}$). If a reader requests data every 10 ms from a writer that only offers 20 ms, the entities will fail to match.
• Notification Mechanisms: Missing a deadline does not disconnect the entity; it triggers a callback on the DataReader’s listener (on_requested_deadline_missed) or updates the entity’s status condition for asynchronous polling.

7. Downsampling Data for Low-Rate Subscribers

The Problem

A high-precision sensor publishes state updates at 200 Hz for the inner control loop. A telemetry logging service or UI dashboard on the same network only needs updates at 5 Hz to conserve CPU and rendering cycles.

Standard QoS Policies

• TIME_BASED_FILTER:
  • Configured on the DataReader.
  • minimum_separation: Minimum time that must elapse between two consecutive samples delivered to this reader.

Trade-offs & Pitfalls

• Local Application Optimization: TIME_BASED_FILTER is evaluated on the DataReader. Samples arriving faster than minimum_separation are discarded before reaching the application layer.
• Independent Readers: Applying a filter on a telemetry reader has zero impact on high-speed readers subscribed to the same topic.

8. Expiring Stale Commands

The Problem

A robot receives velocity nudge commands over a wireless link. If network congestion delays a movement command by 500 ms, executing that command late could cause a collision. The command must automatically expire and be discarded if it cannot be delivered and processed in time.

Standard QoS Policies

• LIFESPAN:
  • Configured on the DataWriter.
  • duration: Specifies how long a sample remains valid after being written.

Trade-offs & Pitfalls

• Automatic Garbage Collection: When duration expires, the middleware removes the sample from both the DataWriter’s history and any matching DataReader caches.
• Clock Dependency: Accurate lifespan calculation across distributed nodes requires synchronized system clocks.

9. Dynamic Fleet Isolation & Multi-Tenancy

The Problem

You are operating multiple autonomous robots or running simulation and hardware nodes on the same local physical network. You want to isolate traffic between Robot 1, Robot 2, and the Simulation environment without changing topic names or recompiling data types.

Standard QoS Policies

• PARTITION:
  • Configured on the Publisher and Subscriber entities.
  • Accepts a list of partition name strings (supports regular expressions and wildcards like "robot_1.*", "zone_a").

Trade-offs & Pitfalls

• Dynamic Reconfiguration: Unlike topics or domain IDs, partition QoS can be modified at runtime without destroying and recreating entities.
• Entity Scope: Partitions are assigned to Publisher/Subscriber containers, not individual DataWriters or DataReaders.

10. Multi-Writer Timestamp Ordering

The Problem

Multiple distributed nodes write updates to the same shared state instance. Because network paths have variable latency, samples might arrive at readers out of the order in which they were actually generated.

Standard QoS Policies

• DESTINATION_ORDER:
  • BY_RECEPTION_TIMESTAMP: Samples are ordered based on when the DataReader receives them.
  • BY_SOURCE_TIMESTAMP: Samples are ordered based on the timestamp recorded by the DataWriter at the moment write() was called.

Trade-offs & Pitfalls

• Dropping Out-of-Order Data: When set to BY_SOURCE_TIMESTAMP, if a sample arrives with a timestamp older than the latest sample already accepted for that instance, the late-arriving sample is dropped.
• Requires Time Synchronization: BY_SOURCE_TIMESTAMP requires accurate clock synchronization across all publishing machines (such as PTP IEEE 1588 or NTP). Without clock sync, writer timestamp skew will cause valid samples to be discarded.

Need Architecture Review or Custom DDS Integration?

Designing distributed real-time systems with complex QoS topologies requires balancing network bandwidth, memory bounds, and latency budgets.

S2E Software Systems specializes in embedded software, real-time middleware architecture, and custom DDS integrations. Contact our team to discuss your system architecture or schedule a diagnostic review.