OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] Commented: (MQTT-102) What does QoS 0 mean? Should it be called "At Most Once"?

    [ http://tools.oasis-open.org/issues/browse/MQTT-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36014#action_36014 ] 

Peter Niblett commented on MQTT-102:

The consensus from the call on November 14 was that we should follow the approach that I called Option 1 in my previous comment. 

We decided that QoS 0 does not, of itself, permit duplication of messages, so we should remove the words "or duplication" from page 1. 

However the effective end-end QoS achieved when sending a message from Publishing client to Subscribed client, depends on the QoS used to send it to the server and the QoS used to forward it from the server to the client.  In many cases these two QoS values are identical. 

In particular if the subscription sets a Max QoS of 2, then the two QoS values will be the same, and the server should be required to respect that QoS when it does the forwarding. This means that the Publisher gets to set the overall QoS, and you get At Least once for 0, At Most once for 1 and Exactly once for 2.

Note that a consequence of this is that a subscriber using Max QoS 2 can't tell what QoS they are going to get unless there's a well established agreement with the Publisher what it is going to do. It can't assume it will never get duplicate messages just because it said Max QoS 2.

Now for the "downgrade" cases:

If the subscriber sets max QoS of 1, then messages published as QoS 2 might get duplicated on the hop to the subscriber (i.e. we sacrifice the "at most once" aspect).  In this case we can presume the subscriber is either happy to do its own deduplication, or trusts the publisher not to send messages where duplicates would matter (ie idempotent messages only). 

f the subscriber sets max QoS of 0, then messages published as QoS 2 might get lost on the hop to the subscriber (i.e. we sacrifice "at least once"), but the server never sends a duplicate - I think this is easy for servers to do.

If the subscriber sets max QoS of 0, then messages published as QoS 1 might get duplicated on the hop to the subscriber.  We justify this by saying that the publisher has set the QoS and  QoS 1 is called "At most once". The wrinkle here is that the subscriber gets no indication of the QoS that was used by the publisher, and no message ID to help with deduplication. 

The moral of all this is that we should advise publishers to be careful about when they use QoS 1, as there's a risk of duplication occuring.  They should only use it if 

1. The messages are truly idempotent. or
2. There's something in the Application Message payload that makes it easy for consuming application logic to do its own deduplication, or
3. They know that the subscribers aren't going to subscribe with max QoS 0

If people agree with all this, I will turn it into a proposal

> What does QoS 0 mean? Should it be called "At Most Once"?
> ---------------------------------------------------------
>                 Key: MQTT-102
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-102
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.1.1
>            Reporter: Peter Niblett
> WD 14 lines 34, 378 and 1254  all refer to QoS 0 as "At most once" (in contrast to QoS 1 which is "At least once", and QoS 2 "Exactly once").  Line 35 goes on to state that for QoS 0 "Message loss or duplication can occur".   However the description of QoS 0 section 4, line 1256 says "The message arrives at the receiver either once or not at all".
> The inclusion of "duplication" in the statement in 35 causes two problems:
> 1. It looks like a mistake to refer to something as "At most once" and at the same time tell people that duplication can occur
> 2. It gives equal status to loss and duplication. Someone implementing (for example) a server or a bridge from another protocol can find themselves in a position where they have a QoS 0 message which might possibly have already been sent. What should they do?  Should they assume that consumers don't care about duplicates and so they should send it just in case, or can they say that consumers don't care about lost messages, so they should discard it ?
> We need to clarify this ambiguity and decide what QoS 0 really means
> a) It really does mean "At most once", in which case we remove the word duplication from 35. We should also add some normative text to say that a sender  should never knowingly send a QoS 0 message that might be a duplicate (i.e. it should err on the side of dropping a message rather than possibly sending a duplicate).
> b) It really does mean "Duplicates and Gaps" (so taken to an absurd extreme a server that continually published message 1 ad infinitum would be compliant). In this case we should stop referring to it as "At most once".
> At risk of complicating things, I would like to add a related point to be considered alongside this issue, and that is the requirement on the use of the DUP flag in QoS 1.  In WD14 line 363 there's a statement that says
> "If Dup -0 then the flow is the first occasion that the client or server has attempted to send the MQTT PUBISH (sic) packet" If DUP 1 then this indicates that the flow might be a re-delivery of an earlier packet".  
> It has been pointed out that a client that always sets DUP 1 would be compliant with this statement, which I am sure was not our intention. I think the statement should be reworded in normative language to say that you MUST set DUP 0 on the first occasion that a packet ID is used, and DUP 1 if you have attempted to send a message with that packet ID previously.. (the precise wording of this would need some work) 

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]