This issue is to start discussing adding of additional QoS to ROS 2. In particular the first two QoS that deem to be really necessary are:

1. Deadline which is needed for when data is needed at constant periodicity (e.g. vehicle data for controller at exactly 1kHz).
2. Liveliness which specifies and configures the mechanism that allows DDSDataReader entities to detect when DDSDataWriter entities become disconnected or "dead. This QoS setting is needed for a heartbeat feature in managed nodes.

General approach

As ROS 2 is C++11/14 it seems natural to implement advanced features alongside the DDS C++11 API described here. While this API is AFAIK not an official DDS standard, or at least I could not find it on the OMG page) Connext Pro and OpenSplice use this exact API.

As most functionality is implemented around the wait-set concept it makes sense to do the same in ROS 2 as the existing callback-based API which is very similar to ROS 1 is not modified.

DDS C++11/14 concept summary:

Everything in DDS is Event-based. Events in DDS are called Conditions.
There are several kinds of Conditions:

Read Conditions

Everything that has to do with the state of a sample or instance (keyed group).
A read condition is triggered when a sample with the attached (Data State)[https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/api/connext_dds/api_cpp2/classdds_1_1sub_1_1status_1_1DataState.html] is received or an existing sample changes to this data state.

Status Condition

Everything that is related to events not to a state of a sample.
Examples:
New data reader/writer detected.
Incompatible QOS detected.
Deadline missed.
DataWriter died.

List of possible status: https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/api/connext_dds/api_cpp2/group__DDSStatusTypesModule.html

Condition management:

The user needs to be able to check if a condition did happen. There are two ways to do this:

• Waitsets: The recommended way by RTI.
• Callbacks: Only recommended for special ultra-low latency applications (can be dangerous) (by RTI)[https://community.rti.com/best-practices/use-waitsets-except-when-you-need-extreme-latency]. Also, the callback based approach is much harder to use in my experience.

So rclcpp should implement the waitset based approach:
https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/api/connext_dds/api_cpp2/classdds_1_1core_1_1cond_1_1WaitSet.html

QOS Configuration

QOS settings must also be configured, which is the easier thing to do.

Deadline:
https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/api/connext_dds/api_cpp2/classdds_1_1core_1_1policy_1_1Deadline.html

Ownership:
https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/api/connext_dds/api_cpp2/group__DDSOwnershipQosModule.html
https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/api/connext_dds/api_cpp2/group__DDSOwnershipStrengthQosModule.html

Liveliness
https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/api/connext_dds/api_cpp2/group__DDSLivelinessQosModule.html

Utility functions

Some utility functions like asserting liveliness and translating instance handles to keys and via versa must also be provided on a DataWriter and DataReader level.