[OASIS Issue Tracker] (MQTT-292) Modify statements about message ordering

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63094#comment-63094 ] 

Ed Briggs commented on MQTT-292:
--------------------------------

I think this is an important point, and I'd like to make some addition observations.  

1. Re-ordering ACKs breaks QoS 1 (it will not be true that the final copy of  of each message received will be in the order originally published)  and QoS 2 as well. In other words, the transmitted sequence {T, {a, b, c}} can not be presented to the receiver as {T, {a, c}}.  (where a, b, c represent three different commands mapped to unique packet identifiers carried on transport session T).  If this occurs, MQTT's recovery mechanism cannot 'repair' the gap and restore ordered delivery (or QoS 1 delivery). Essentially, an out-of-order ack creates a 'hole' in the retransmission list. It doesn't matter what the source of re-ordering was (in this case, you're considering that it is introduced by something other than transport).

2. The non-normative statement about the in-flight window = 1 and ordering is false, and unfortunately leads some users to use w=1  resulting in abysmal throughput and delay - all the in mistaken belief this is beneficial. More broadly, there is a lack of clarity between end-to-end delivery guarantees and delivery guarantees between session partners and is the source of much confusion among MQTT users.

> Modify statements about message ordering
> ----------------------------------------
>
>                 Key: MQTT-292
>                 URL: https://issues.oasis-open.org/browse/MQTT-292
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: futures
>    Affects Versions: 5
>            Reporter: Ken Borgendale
>
> Section 4.6 message ordering has a number of imperatives which cause problems for large distributed severs but which do not give any value in terms of message ordering.
> The three ACK order mandatory normative statements (MQTT-4.6.0-2, MQTT-4.6.0-3, and MQTT-4.6.0-4) require that the ACKs be send back in the order of the publish. This is orthogonal to the messages being forwarded in order.  While this (when applied to servers) might be of value to clients, no client can realistically depend on them as they cannot know the configuration of the server (which is allowed to be configured to not ordered).  
> It would seem to make equal sense for a client to be allowed to process a topic unordered if so configured.
> There is a specific problem with ACK order at session recovery and when ACKs are sent as retry.
> The non-normative statements in the section should also be reworked.  The second one is clearly false.  Setting the in-flight window to 1 in no way guarantees the order of QoS=0 messages relative to QoS>0 messages.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)