CEO / CTO Angelo Corsaro, PhD QoS — DDS vs Zenoh

Prelude The OMG DDS provides 22 QoS Policies There are a series of myths and belief around some of these QoS induced by their names and the generally assumed implications In this presentation will spell out what DDS’s QoS really guarantees and how the map to Zenoh

DDS QoS Review

DDS QoS DDS provides 22 QoS standard QoS Some of these are immutable and cannot be changed once an entity is created Some of these QoS are Request vs O ff ered and in fl uence Reader/Writer matching HISTORY LIFESPAN DURABILITY DEADLINE LATENCY BUDGET TRANSPORT PRIO TIME-BASED FILTER RESOURCE LIMITS USER DATA TOPIC DATA GROUP DATA OWENERSHIP OWN. STRENGTH LIVELINESS ENTITY FACTORY DW LIFECYCLE DR LIFECYCLE PRESENTATION RELIABILITY PARTITION DEST. ORDER RxO QoS Local QoS Immutable

Temporal Properties

Temporal Properties The Deadline QoS is a local watchdog that noti fi es when a data-reader (-writer) is not receiving (writing) data at the expected rate It has not impact on the network scheduling Throughput TimeBasedFilter [Inbound] [Outbound] Latency Deadline TransportPriority LatencyBudget

Temporal Properties The TimeBasedFilter does not reduce network tra ffi c when using multicast (which is the most common deployment case) Thus, samples are dropped at the receiving side Throughput TimeBasedFilter [Inbound] [Outbound] Latency Deadline TransportPriority LatencyBudget

Temporal Properties The TransportPriority QoS is just a hint and the DDS speci fi cation does not provide any guarantees that it will have any impact on tra ffi c scheduling That is entirely vendor dependent Throughput TimeBasedFilter [Inbound] [Outbound] Latency Deadline TransportPriority LatencyBudget

Temporal Properties In short, the DDS speci fi cation does not provide any real mechanism to control the temporal properties of data It provides mechanism to detect deadline violations — notably the Deadline QoS

Data Delivery

Data Delivery The reliability QoS should not be thought as providing “reliability” as you are used with TCP/IP It is actually a combination of Reliability and History that controls reliability and this makes it rather complex for people to understand Reliability Presentation Destination Order Partition Ownership Ownership Strength Data Delivery

Data Delivery The Partition is a QoS that controls the scope of the data While this QoS is changeable, it is not recommended to do so since applications may receive data they are not supposed to FYI we demonstrated how this happens and forced DDS security to make this QoS un-mutable Reliability Presentation Destination Order Partition Ownership Ownership Strength Data Delivery

Data Delivery Presentation, not implemented by vendors Ownership and Ownership strength allow to automatically fi lter data from multiple writers (based on strength), but the fi ltering happens on the receiving side — thus no bandwidth saving Reliability Presentation Destination Order Partition Ownership Ownership Strength Data Delivery

Data Availability

Data Availability Lifespan is like a TTL, again controls the expiry of data on the receiving side History is a weird one as it impacts both reliability and data available to late joiners Controls under which circumstances late joiners receive data History Durability Lifespan Data Availability Durabiliy Service

Mapping DDS QoS to Zenoh

Simplicity is the Ultimate Sophistication Zenoh has an extremely simple API and often people mistake simplicity with lack of features — especially when comparing to the complexity of DDS

Mapping DDS QoS to Zenoh DDS QoS Policy Scope Zenoh Scope Notes Reliability + History Reader/ Writer Reliability + Congestion Control Sample/ Publisher Transport Priority Writer/ Sample Priority Class Sample/ Publisher Transport Priority is a hint on DDS while it is respected end-to-end in Zenoh Partition Publisher/ Subscriber Key Expression Publisher/ Subscriber/ Sample Latency Budget Writer Automatic Batching - Unnecessary in Zenoh, network scheduling is done by automatically the protocol Deadline Writer/ Reader - - Zenoh considers this as an API facility and is provided in languages is irrelevant on some languages, such as Rust

Mapping DDS QoS to Zenoh DDS QoS Policy Scope Zenoh Scope Notes Time Based Filter Reader - - Real rate limiting is supported by Zenoh by interceptors which can be con fi gured on peers or infrastructural nodes, i.e., Zenoh routers Durability Reader/ Writer Distributed Queries - Zenoh supports distributed queries as a fi rst class citizen. This is far more generic and powerful than DDS durability Liveliness Reader/ Writer Scalable Liveliness Protocol Zenoh has a scalable liveliness protocol that does not su ff er the quadratic problems of DDS liveliness Ownership/ Ownership Strength Writer/ Reader Group Management + Leader Election Custom Zenoh provides a group management and leader election as part of a library extension

Patience, persistence and perspiration make an unbeatable combination for success. Thank You