Summary and typical use cases for different Quality of Service (QoS) parameters

The follow list describes each of the Quality of Service (QoS) parameters and some common use cases for them.

Asynchronous Publisher

Configures the mechanism that sends user data in an external middleware thread.

• Can be used to reduce the amount of time spent in the user thread to send data.
• In RTI Connext 7.3.0 and below, it must be used to send "large" data reliably. "Large" is defined as data that cannot be sent as a single packet by a transport. For example, to send data larger than 63K reliably using UDP/IP, you must configure DDS to send the data using asynchronous publishers. Starting in release 7.4.0, this is no longer a requirement.
• For small samples, it can be used to reduce bandwidth consumption. Using an asynchronous publisher we get aggregation of samples (collecting many RTPS data samples into one network packet) since samples written for the same topic to the same destination are coalesced within the same UDP packet, which reduces bandwidth. For bandwidth reduction, see also Batch Qos
• Also see: Publish Mode QoS.

Batch

Specifies and configures the mechanism that allows the middleware to collect multiple user data samples to be sent in a single network packet. This allows you to take advantage of the efficiency of sending larger packets and thus increase effective throughput.

• It can be used to dramatically increase the effective throughput for small data packets. Usually, throughput for small data packets (data < 2048 bytes) is limited by CPU capacity and not by network bandwidth. Batching many smaller data packets so they are sent in one large data packet will increase network utilization and thus throughput in terms of user data packets per second.

Database

Various threads and resource limits settings used by RTI Connext to control its internal database.

• Really just a list of lists, RTI uses an internal "database" to store information about DDS entities created locally as well as remote entities of other DDS participants found during the discovery process.
• The Database QoS is used to configure how RTI  Connext manages its database including how often its clean up, the priority of the database thread, and limits on resources that may be allocated by the database.
• Users may be interested in modifying the shutdown_timeout andshutdown_cleanup_period parameters to decrease the time it takes to delete a DDSDomainParticipant when their application is shutting down.  

DataReader Resource Limits

Various settings that configure how DataReaders allocate and utilize physical memory for internal resources.

• DataReaders must allocate internal structures to handle the maximum number of DataWriters that may connect to it, whether or not a DataReader handles data fragmentation and how many data fragments that it may handle, how many simultaneous, outstanding loans of internal memory holding data samples can be provided to user code, as well as others.
• Most of these internal structures start at an initial size and by default, will be grown as needed by dynamically allocating additional memory.  Users may set fixed, maximum sizes for these internal structures if they want to bound the amount of memory that can be used by a DataReader.  By setting the initial size to the maximum size, users will prevent RTI Connext from dynamically allocating any memory after the creation of the DataReader.

DataWriter Resource Limits

Various settings that configure how DataWriters allocate and utilize physical memory for internal resources.

• DataWriters must allocate internal structures to handle the simultaneously blocking of threads trying to call write() on the same DataWriter, for the storage used by Batch-ed DataWriters, and for filters for Content-Based Filtering DataReaders.
• Most of these internal structures start at an initial size and by default, will be grown as needed by dynamically allocating additional memory.  Users may set fixed, maximum sizes for these internal structures if they want to bound the amount of memory that can be used by a DataWriter.  By setting the initial size to the maximum size, users will prevent RTI Connext from dynamically allocating any memory after the creation of the DataWriter.

DataWriter Protocol, DataReader Protocol

Along with the Wire Protocol QoS, this QoS configures the DDS on-the-wire protocol (RTPS).

• DDS has a standard protocol for packet (user and meta data) exchange between applications using DDS for communications. The Protocol QoS gives you control over configurable portions of the protocol, including the configuration of the reliable data delivery mechanism of the protocol on a per datawriter or datareader basis.
• These configuration parameters control timing and timeouts, and give you the ability to tradeoff between speed of data-loss detection and repair, versus the network and CPU bandwidth used to maintain reliability.
• It is important to tune the reliability protocol (on a per DataWriter and DataReader basis) to meet the requirements of the end-user application so that data can be sent between DataWriters and DataReaders in an efficient and optimal manner in the presence of data loss. You can also use this QoS to control how DDS responds to "slow" reliable DataReaders or ones that disconnect or are otherwise lost.
• See the Reliability QoS for more information on the per-datareader/datawriter reliability configuration.
• In addition, the History and Resource Limits QoS policies play an important role in the DDS reliable protocol.

Deadline

For a DataReader, this QoS specifies the maximum expected elapsed time between arriving data samples if data is unkeyed or instances if data is keyed. For a DataWriter, it specifies a commitment to publish samples or instances with no greater than this elapsed time between them.

• Can be used during system integration to ensure that applications have been coded to meet design specifications.
• Can be used during run time to detect when systems are performing outside of design specifications. Receiving applications can take appropriate actions to prevent total system failure when data is not received in time. For topics on which data is not expected to be periodic, the deadline period should be set to an infinite value.

Destination Order 

Controls how the middleware will deal with data sent by multiple DataWriters for the same topic. Can be set to "by reception timestamp" or "by source timestamp".

• When multiple DataWriters send data for the same Topic, the order in which data from different DataWriters is received by the applications of different DataReaders may be different. So different DataReaders may not receive the same "last" value when DataWriters stop sending data.
• If using "by reception timestamp", data will be delivered by a DataReader in the order in which it was received (which may lead to inconsistent final values).
• If using "by source timestamp", data will be delivered by a DataReader in the order in which it was sent. If data arrives on the network with a source timestamp earlier than the source timestamp of the last data delivered, the new data will be dropped. This ordering therefore works best when system clocks are relatively synchronized among writing machines.
• When using "by source timestamp", not all data sent by multiple DataWriters may be delivered to a DataReader, and not all DataReaders will see the same data sent by DataWriters. However, all DataReaders will see the same "final" data when DataWriters stop sending data.
• This QoS Policy can be used to create systems that have the property of "eventual consistency". Thus intermediate states across multiple applications may be inconsistent, but when DataWriters stop sending changes to the same topic, all applications will end up having the same state.

Discovery

Configures the mechanism used by the middleware to automatically discover and connect with new remote applications.

• Identifies where on the network this application can potentially discover other applications with which to communicate. This is done via an initial peers list.  The middleware will periodically send network packets to these locations, announcing itself to any remote applications that may be present, and will listen for announcements from those applications.

Discovery Config

Configures the mechanism used by the middleware to automatically discover and connect with new remote applications.

• The amount of network traffic required by the discovery process can vary widely, based on how your application has configured the middleware's network addressing (e.g., unicast vs. multicast, multicast TTL, etc.), the size of the system, whether all applications are started at the same time or whether start times are staggered, and other factors. Your application can use this policy to make tradeoffs between discovery completion time and network bandwidth utilization. In addition, you can introduce random back-off periods into the discovery process to decrease the probability of network contention when many applications start simultaneously. See also: Discovery QoS.

DomainParticipant Resource Limits

Various settings that configure how DomainParticipants allocate and utilize physical memory for internal resources, including the maximum sizes of various properties.

Durability

Specifies whether or not the middleware will store and deliver previously published data to new/late joining DataReaders.

• Allows new DataReaders to receive data that were previously sent by DataWriters.
• Helps ensure that DataReaders get all data that was sent by DataWriters, regardless of when it was sent.
• Can increase system tolerance to failure conditions.

Group Data

Along with the Topic Data and User Data QoS Policies, Group Data is used to attach a buffer of bytes to the middleware's discovery meta-data.

• Often used to attach extra data that the user wants to propagate at discovery time. This extra data is interpreted by your application and not used by the middleware itself.
• Use cases for the Topic, Group, and User Data QoS Policies are often for application-to-application identification, authentication, authorization and encryption purposes. For example, applications can use Group or User Data to send security certificates to each other for RSA-type security.

History

Specifies how much data must be stored per instance by the middleware for the DataWriter or DataReader. This QoS policy affects the Reliability and Durability QoS policies.

• When a DataWriter sends data or a DataReader receives data, the data sent or received is stored in a cache whose contents are controlled by the History QoS policy. The History QoS policy can tell the middleware to store ALL of the data that was sent or received, or only store the LAST N instances sent or received. If the History QoS policy is set to keep the last N instance values, then after N values have been sent or received, any new data for that particular instance will overwrite the oldest data in the queue. The queue acts like a circular buffer of length N.
• This QoS policy interacts with the Reliable QoS policy by controlling whether or not DDS guarantees that (a) all of the data sent is received (using the ALL setting of the History QoS policy) or (b) that only the last N data values per instance sent are received (a reduced level of reliability, using the KEEP LAST setting of the History QoS policy). See the Reliability QoS policy for more information.
• However, the physical size of the send and receive queues are not controlled by the History QoS Policy. The memory allocation for the queues is controlled by the Resource Limits QoS policy.
• Also, the amount of data sent to new DataReaders whose Durability QoS policy is set to receive previously published data is controlled by the History QoS Policy.

Latency Budget

A suggestion to the middleware on how much time is allowed to deliver data.

• Can be used by a DDS implementation to change how it processes and sends data that has low latency requirements.
• The DDS specification does not mandate whether or how this parameter is used. RTI Connext uses it to prioritize the sending of asynchronously published data; see Asynchronous Publisher QoS policy.

Lifespan

Specifies how long the middleware should consider data sent by a user application to be valid.

• The middleware attaches timestamps to all data sent and received. When you specify a finite Lifespan for your data, the middleware will compare the current time with those timestamps and drop data when your specified Lifespan expires.
• The Lifespan QoS policy can be used to control how much data is stored by the middleware. Even if it is configured to store "all" of the data sent or received for a topic (see the History QoS policy), the total amount of data it stores may be limited by the Lifespan QoS policy.
• You may also use the Lifespan QoS Policy to ensure that applications do not receive or act on data, commands or messages that are too old and have "expired".

Liveliness

Specifies and configures the mechanism that allow DataReaders to detect when DataWriters become disconnected or "dead".

• Used during system integration to ensure that applications have been coded to meet design specifications.
• Used during run time to detect when systems are performing outside of design specifications. Receiving applications can take appropriate actions in response to disconnected DataWriters.

Ownership and Ownership strength

Along with Ownership Strength, Ownership specifies if a DataReader can receive data for an instance of data from multiple DataWriters at the same time.

• By default, DataReaders for a given topic can receive data from any DataWriter for the same topic. This is the "shared" setting for the Ownership QoS Policy.
• You can also configure an application to use "exclusive" ownership for a topic. The exclusive setting only allows DataReaders to receive data from one DataWriter at a time.  Ownership applies on a per key value (instance) basis for Topics that are keyed. Thus, with exclusive Ownership, DataReaders will only receive data from a single DataWriter for a particular instance (unique value for the key) of a Topic. This implies that a DataReader may receive data from multiple DataWriters as long as the DataWriters are sending data for different instances.
• The middleware will use the Ownership Strength to decide which DataWriter's data will be delivered to DataReaders. The DataWriter with the highest Ownership Strength value will be the owner of the instances and whose data is delivered to DataReaders. Instances sent by all other DataWriters with lower Ownership Strength will be dropped by the middleware. (An arbitrary but deterministic method is used to select a single DataWriter among multiple DataWriters with the same highest Ownership Strength).
• When the DataWriter with the highest Ownership strength loses its liveliness (as controlled by the Liveliness QoS policy) or misses a deadline (as controlled by the Deadline QoS policy) or whose application quits, dies or otherwise disconnects, the middleware will change ownership of the topic or instances to the DataWriter with the highest Ownership Strength from the remaining DataWriters.
• This QoS policy can help you build systems that have redundant elements to safeguard against component or application failures. When systems have active and hot standby components, the Ownership QoS policy can be used to ensure that data from standby applications are only delivered in the case of the failure of the primary.
• The Ownership QoS policy can also be used to create data channels or Topics that are designed to be taken over by external applications for testing or maintenance purposes.

Partition

Adds additional string identifiers for matching DataReaders and DataWriters for the same DDS topic.

• Usually DataReaders and DataWriters are matched by their topic (so that data are only sent by DataWriters to DataReaders for the same topic). You can also use the Partition QoS policy to add one or more strings, "partitions," to a publisher and/or subscriber. If partitions are added, then a DataWriter and DataReader for the same topic are only considered matched if their publishers and subscribers have partitions in common (intersecting partitions).
• Partition strings are usually directly matched via string compares. However, partition strings can also contain wildcard symbols so that partitions can be matched via pattern matching. As long as the partitions or wildcard patterns of a publisher intersects with the partitions or wildcard patterns of a subscriber, their DataWriters and DataReaders of the same topic are considered matched, otherwise they are not. The middleware will not deliver data between DataWriters and DataReaders of the same topic unless they have intersecting partitions (if and when the Partition QoS policy is used).
• Since the set of partitions for a publisher or subscriber can be dynamically changed, the Partition QoS Policy is useful to control which DataWriters can send data to which DataReaders and vice versa, even if all the DataWriters and DataReaders are for the same topic. This facility is useful for creating temporary separation groups among entities that would otherwise be connected to and exchange data each other.

Presentation

Controls how DDS presents data received by an application to the DataReaders of the data.

• Usually DataReaders will receive data in the order that the data was sent by a DataWriter. (When using reliability Qos, samples which arrive out of order, it will be buffered until all previous samples arrive.) Once in order, data is presented to the DataReader immediately. 
• Sometimes, you may want a set of data for the same topic to be presented to the receiving DataReader only after ALL of the elements of the set have been received, but not before.
• Also, you may want the data to be presented in a different order than it was received. Specifically, for keyed data, you may want DDS to present the data in keyed or instance order.
• The Presentation QoS Policy allows you to specify different scopes of presentation, within a topic, across instances of a topic, and even across different topics of a publisher. It also controls whether or not a set of changes within the scope is delivered at the same time or can be delivered as soon as each element is received.

Publish Mode

Specifies the mechanism that sends user data in an external middleware thread. By default, data is sent in the user thread that calls DDSDataWriter::write(). However, this QoS policy can be used to tell the middleware to use its own thread to send the data.  Also see: Asynchronous Publisher QoS.

• The fastest way for DDS to send data is for the user thread to execute the middleware code that actually sends the data itself. However, there are times when user applications may need or want an internal middleware thread to send the data instead.
• For instance, in RTI Connext 7.3.0 and below, to send large data reliably, an asynchronous thread must be used (see Asynchronous Publisher QoS policy). Starting in release 7.4.0, this is no longer a requirement.
• In addition, this QoS policy can select a flow controller to "shape" the data flow sent by a DataWriter to DataReaders. "Shaping" a data flow usually means limiting the maximum data rates with which the middleware will send data for a DataWriter. The flow controller will buffer data sent faster than the maximum rate by the DataWriter, and then only send the excess data when the send rate drops below the maximum rate.

Reliability

Specifies whether or not DDS will deliver data reliably.

• The reliability of a connection between a DataWriter and DataReader is entirely user configurable. It can be done on a per DataWriter/DataReader connection. A connection may be configured to be "best effort" which means that DDS will not use any resources to monitor or guarantee that the data sent by a DataWriter is received by a DataReader.
• For some use cases, such as the periodic update of sensor values to a GUI displaying the value to a person, "best effort" delivery is often good enough. It is certainly the fastest, most efficient, and least resource-intensive (CPU and network bandwidth) method of getting the newest/latest value for a topic from DataWriters to DataReaders. But there is no guarantee that the data sent will be received. It may be lost due to a variety of factors, including data loss by the physical transport such as wireless RF or even Ethernet.
• However, there are data streams (topics) in which you want an absolute guarantee that all data sent by a DataWriter is received reliably by DataReaders. This means that DDS must check whether or not data was received, and repair any data that was lost by resending a copy of the data as many times as it takes for the DataReader to receive the data.
• DDS uses a reliability protocol configured and tuned by these QoS policies: History, DataWriter Protocol, DataReader Protocol, and Resource Limits.
• The Reliable QoS policy is simply a switch to turn on the reliability protocol for a DataWriter/DataReader connection. The level of reliability provided by the middleware is determined by the configuration of the aforementioned QoS policies.
• You can configure the middleware to deliver ALL data in the order they were sent (also known as absolute or strict reliability). Or, as a tradeoff for less memory, CPU, and network usage, you can choose a reduced level of reliability where only the last N values are guaranteed to be delivered reliably to DataReaders (where N is user-configurable). In the reduced level of reliability, there are no guarantees that data sent before the last N are received; only the last Ndata packets are monitored and repaired if necessary.

Resource Limits

Controls the amount of physical memory allocated for middleware entities, if dynamic allocations are allowed, and how they occur. Also controls memory usage among different instance values for keyed topics.

• For the reliability protocol (and the Durability QoS policy), this QoS policy determines the actual maximum queue size when the History QoS policy is set to KEEP ALL.
• In general, this QoS policy is used to limit the amount of system memory that DDS can allocate. For embedded real-time systems and safety-critical systems, pre-determination of maximum memory usage is often required. In addition, dynamic memory allocation could introduce non-deterministic latencies in time-critical paths.
• This QoS policy can be set so that an entity does not dynamically allocate more memory after its initialization phase.

Time-based Filter

Set on a DataReader to limit the number of new data for each instance received over a period of time.

• You can use this QoS policy to reduce the amount of data per instance received by a DataReader. DataWriters may send data faster than needed by a DataReader. For example, a DataReader of sensor data that is displayed to a human operator in a GUI application does not need to receive data updates faster than a user can reasonably perceive changes in data values. This is often measure in tenths (0.1) of a second up to several seconds. However, a DataWriter of sensor information may have DataReaders that are processing the sensor information to control parts of the system and thus need new data updates in measures of hundredths (0.01) or thousandths (0.001) of a second.
• With this QoS policy, different DataReaders can set their own time-based filters, so that data published faster than the period set by a DataReader will be dropped by the middleware and not delivered to the DataReader.
• This QoS policy allows you to optimize resource usage (CPU and possibly network bandwidth) by only delivering the required amount of data to different DataReaders.

Transport Multicast

Specifies the multicast address on which a DataReader wants to receive its data. Can also specify a port number as well as a subset of the available transports with which to receive the multicast data.

• By default, DataWriters will send individually addressed packets for each DataReader that subscribes to the topic of the DataWriter -- this is known as unicast delivery. One copy of the data will be sent over the network for each DataReader. The network bandwidth used by a DataWriter will thus increase linearly with the number of DataReaders.
• Multicast addressing (on UDP/IP transports) allows multiple DataReaders to receive the samenetwork packet. By using multicast, a DataWriter can send a single network packet that will be received by all subscribing applications. Thus the network bandwidth usage will be constant and independent of the number of DataReaders.
• Coordinating the multicast address specified by DataReaders can help optimize network bandwidth usage in systems where there are multiple DataReaders for the same DDS topic.

Transport Priority

Set on a DataWriter to tell DDS that the data being sent is a different "priority" than other data.

• This QoS policy is optional and only partially supported on certain OSs and transports by RTI. However, its intention is to allow you to specify on a per-DataWriter basis that data sent by a DataWriter is of a different priority. It is not specified by DDS how a DDS implementation shall treat data of different priorities. It is often difficult or impossible for DDS implementations to treat data of higher priority differently than data of lower priority, especially when the data is sent (delivered to a physical transport) directly by the thread that called DataWriter::write(). Also, many physical network transports themselves do not have a end-user controllable level of data packet priority.

Transport Selection

Allows you to select which physical transports a DataWriter or DataReader may use to send or receive its data.

• An application may be connected to many different physical transport simultaneously, e.g., Ethernet, Infiniband, shared memory, VME backplane, and wireless. By default, the middleware will use up to 4 transports to deliver data from a DataWriter to a DataReader.
• This QoS policy can be used to limit and control which of an application's available transports may be used by a DataWriter to send data or by a DataReader to receive data.

User Data

Along with the Topic Data and Group Data QoS policies, this policy is used to attach a buffer of bytes to the middleware's discovery meta-data.

• Often used to attach extra data that you want propagated at discovery time. This extra data is interpreted by the end user application and is not used by the DDS middleware itself.
• Use cases for the Topic, Group, and User Data QoS policies are usually for application-to-application identification, authentication, authorization, and encryption purposes. For example, applications can use Group or User Data to send security certificates to each other for RSA-type security.

Wire Protocol

Along with the the Protocol QoS policy, this QoS configures the DDS on-the-wire protocol (RTPS).

• This QoS policy configures some global properties of the DDS on-the-wire protocol, RTPS. The DataWriter and DataReader Protocol QoS policies configure RTPS and reliability properties on a per DataWriter or DataReader basis.