QoS history policy in case of durability 'volatile' and reliability 'best effort'

Question

Consider a ROS 2 QoS with:

• Durability policy Transient local,
• Reliability policy Reliable, and
• History policy Keep last 5

This makes sense: the publisher will ensure message are delivered, and it will send the last 5 messages to late-joining subscribers.

Similarly, consider a ROS 2 QoS with:

• Durability policy Transient local,
• Reliability policy Best effort, and
• History policy Keep last 5

This also makes sense: the publisher will send the last 5 messages to late-joining subscribers, but it does not care if a message isn't received.

However, following combinations are less clear to me:

A ROS 2 QoS with:

• Durability policy Volatile,
• Reliability policy Reliable, and
• History policy Keep last 5

--> Does Keep last 5 make sense here? Late-joining subscribers only get the next published message, so why keep a buffer of 5? Only reason I see is maybe due to the Reliable policy, you need a buffer so publish calls don't block (or fail?) in case sending takes a long time if multiple retries are needed to deliver a message?

A ROS 2 QoS with:

• Durability policy Volatile,
• Reliability policy Best Effort, and
• History policy Keep last 5

This is a default ROS 2 QoS policy: the SensorDataQoS, see also rmw_qos_profile_sensor_data.
However, what is the benefit of having a buffer > 1 here? I think of maybe one use case: if there is a burst of up to 5 publish calls, faster than the actual messages can be sent through the rmw, then due to the buffer no messages will be dropped, whereas for Keep last 1 any consecutive publish call at a higher pace than the actual sending of the messages would be dropped? Obviously this only deals with the case of short bursts; if the average publish rate is higher than the sending rate, any buffer size will fill eventually.

See also this question where long latencies are reported in case of SensorDataQoS with depth 5, as opposed to "normal latencies for history 1". So: is it recommended to use a buffer size of 1 if no bursts are expected?

Answer 1

This is a tricky subject and there's some related discussion is scattered through some old Q&A posts, issues, and the ROS2 Docs.

It helps to understand that QoS settings are used for both the publisher and the subscriber, and while they are often be the same, they don't have to match exactly. See the Compatibility tables in the ROS2 Docs for more details. E.g. you could have a Transient Local Publisher with a Volatile Subscriber.

Taking the SensorDataQos as an example: this profile is geared towards subscribers listening to image topics. Because image transport is so bandwidth heavy, you often want Best Effort reliability and you probably don't want to send the whole backlog of old images to late joining subscribers who are probably just processing frames in real time as they come in.

My understanding is that setting the History Depth for Volatile QoS can play a role primarily in the case of "bursts" of data that are published faster than they can be transmitted or processed by the subscriber's callback.

E.g. imagine your image subscriber has some variable duration image processing algorithm that sometimes takes longer than the period in which new images are published, and it is still processing the first image when the next one comes in. This isn't a "historic" message so you would still want to receive it. I believe the History depth of 5 will allow it to buffer that next message and process it once the callback of the first message completes.

As you mentioned, there's a similar use case for buffering bursts of messages on the Publisher side, where the transport over the network can't keep up with the rate at which messages are getting published.

I can't personally speak to the impact of History depth on pub/sub latency. I'd imagine it depends quite a bit on the application. My guess is that the depth of 5 is a "happy medium" that was selected to have things behave "as expected" in a broad set of applications, but that might not necessarily be the optimal QoS for your application.