11.5 Control Plane QoS Expectations [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 11.5 Control Plane QoS Expectations ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:11-control-plane-topics:start | Return to Control Plane Topics ]]

The [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] should use [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] QoS settings that support reliable operational visibility without overcomplicating the Phase 0 [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]]. The team should document the QoS expectations for each Control Plane Topic in the Topic Catalogue and in the relevant DDS Configuration files.

For the Node Status Topic, the team should consider QoS settings that support reliable delivery of important [[dido:99_annexes:annex-b-terms-and-definitions:l:lifecycle|Lifecycle]] transitions. The Topic may also need durability or history settings if late-joining observers must see the most recent Node status.

For the Node Command Topic, the team should consider QoS settings to ensure reliable command delivery and prevent silent command loss. Command messages may also need lifespan or deadline-related settings if stale commands should not execute.

The Phase 0 Baseline should not rely on undocumented DDS defaults that affect observable behavior. If reliability, durability, history depth, lifespan, liveliness, deadline, or ownership matter to the Topic, the team should document the expected QoS policy and validate that the selected DDS tooling applies it.

If later phases support multiple DDS vendors, the team should verify QoS behavior across the supported products or identify vendor-specific constraints in the applicable tool Baseline checklist instance and Topic Catalogue.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>