Legend

• edge client = publishing client

• host client = consuming client

Why do we use MQTT QoS 0 for Sparkplug Birth and Data messages? 

• Why not QoS 1 or 2? 

• QoS 1 and 2 messages can be persisted on the MQTT server

• QoS 1 and 2 messages can be persisted on the server side when a host (consuming) client (e.g., MQTT Engine) goes offline. These messages will be stored until the host client comes back online. In most OT control systems, you do not want old messages to be treated as “live” and take actions like opening/closing of valves far later than when the message was originally published.

• Not only do we have to worry about old messages arriving late to host clients, but we also have to worry about the impact on MQTT server resources (RAM and/or disk depending on implementation) when messages are persisted server-side. At large scale, servers will run out of resources quickly.

• QoS 1 and 2 messages have higher publish-to-receive times due to the additional client-server handshaking.

• How to ensure data is not lost when using QoS 0?

• Sparkplug Sessions and Primary Host ID

• Sparkplug sessions and use of the Primary Host Id ensure the edge client (e.g., MQTT Transmission) is connected to the MQTT server at the same time as the host client (e.g., MQTT Engine), so we know we are good to publish data messages when in an established session.

• MQTT Store and Forward at the edge

• Sparkplug’s use of MQTT Store and Forward at the edge allows the edge client to buffer data locally if the host is offline or the edge connection to the MQTT server is down.

• MQTT Keep Alive

• MQTT client-server connections will fail ungracefully. When this happens the client still has an open socket on its side and is publishing data that will never make it to the MQTT server. MQTT messages will be lost if published after a connection fails ungracefully, but before the client realizes the connection has failed. MQTT provides a mechanism to identify failed connections like this - the MQTT Keep Alive. The MQTT Keep Alive requires that the client send a Ping Request to the server every 1.5x the client’s keep alive (typically 30 seconds). The server must respond with a Ping Response in 1.5x the client’s keep alive setting. When either side fails to get the appropriate request/response, it determines the connection has failed and takes the appropriate action. In the case of the Sparkplug edge client, it will typically be configured to store all tag changes locally in the MQTT Store and Forward History Store until the connection to the server is reestablished. To mitigate the possibility of data loss in the MQTT keep alive window, Cirrus Link has implemented a rolling buffer that covers 2x the client’s keep alive and it contains all tag changes that happened in that window. If the edge client loses connection to the MQTT server, it will flush the rolling buffer once the connection is restored to replay any potentially lost MQTT messages.

• Sparkplug Message Sequence Numbers

• If any message is lost due to some random network issue, but the connection never fails the keep alive (unlikely), a message would actually be lost. This lost message would be identified by the host client because a message sequence number would be missing.

To summarize, data loss with QoS 0 messages can occur in the MQTT keep alive window when a connection fails ungracefully. To mitigate this risk, Sparkplug uses Primary Host Id, and MQTT Store and Forward at the edge with a rolling buffer*. This will not guarantee zero data loss, but it will provide the highest possibility of delivering high speed OT data at scale with a minimal possibility of data loss. 

*Rolling buffer is a Cirrus Link solution implemented on top of Sparkplug and is not in the Sparkplug spec currently.