Changes in QoS 1 and 2 in MQTT 5

Question

According to HiveMQ site here: https://www.hivemq.com/blog/mqtt5-essentials-part2-foundational-changes-in-the-protocol/ a big difference between QoS1 and 2 in version 5 is that "for healthy connection there is no retry" for messages which don't come to destination. I am not sure about the following point:

• I had a look at the standard, I didn't find any mention about it, can someone confirm this is true?
• Does it mean that if the connection breaks while messages are in-flight or messages are not acknowledged because the receiver is not reachable are the only case where there will be a re transmission?
• What about a network congestion but PINGREQ/PINGRES still work?

Answer 1

The V5 spec states:

When a Client reconnects with Clean Start set to 0 and a session is present, both the Client and Server MUST resend any unacknowledged PUBLISH packets (where QoS > 0) and PUBREL packets using their original Packet Identifiers. This is the only circumstance where a Client or Server is REQUIRED to resend messages. Clients and Servers MUST NOT resend messages at any other time [MQTT-4.4.0-1].

The "MUST NOT" is a change from the V3 spec (which permitted resending but did not require it). I believe that this answers your second question (the spec is pretty clear that messages must not be resent other than after a reconnection).

What about a network congestion but PINGREQ/PINGRES still work?

When a PINGREQ is received a PINGRESP will be sent; if network congestion prevents delivery within the allowed time window then the connection will be dropped; otherwise it will stay up. TCP provides a guarantee of in order packet delivery so messages should get through eventually (I realise that this does not always work 100%).

I cannot say why this change was made in the v5 spec but the article you are reading states:

In practice, this is a very bad idea, since overloaded MQTT clients may get overloaded even more.

Mosquitto dropped support for retries in version 1.5 giving the following reasons:

Outgoing messages with QoS>1 are no longer retried after a timeout period. Messages will be retried when a client reconnects. This change in behaviour can be justified by considering when the timeout may have occurred.

• If a connection is unreliable and has dropped, but without one end noticing, the messages will be retried on reconnection. Sending additional PUBLISH or PUBREL would not have changed anything.
• If a client is overloaded/unable to respond/has a slow connection then sending additional PUBLISH or PUBREL would not help the client catch up. Once the backlog has cleared the client will respond. If it is not able to catch up, sending additional duplicates would not help either.