Summary of MQTT-236 Discussions (Consolidate ACKs, enable NAKs)

Size: px

Start display at page:

Download "Summary of MQTT-236 Discussions (Consolidate ACKs, enable NAKs)"

Juliana Atkinson
5 years ago
Views:

1 Summary of MQTT-236 Discussions (Consolidate ACKs, enable NAKs) Microsoft Corporation OASIS MQTT-TC December 10, 2015

2 Notice This is a summary of recent discussion and activities. It may contain errors and omissions, and the information is subject to change. The contents are the opinions of the author and may or may not reflect others thoughts and options. 2

3 Outline Introduction Current Status Open Issues Next Steps 3

4 Thanks I wish to thank Dr. Andrew Banks and Ken Borgendale for their effort and participation in this work. Any errors or omissions are my fault, and not theirs. 4

5 MQTT-236 introduction and Status Andrew Banks wrote the JIRA which provides a method of encoding ACK and NACKs, and includes a comprehensive set of error codes. Microsoft took an action item to work with Andrew and Ken Borgendale offline with the goal of accelerating progress specifically in the area of how NAKs should be handled by the sender and receiver. We are providing this update to the TC on the progress, and open issues. We invite comments on the early discussions. We are working our way through the protocol exchanges at the various QoS levels. There is much work to do. Our goal is to have something firmer by the January meeting at Hursley. 5

6 Encoding MQTT-236 suggests consolidating all the acks into a single packet type and uses bits 3-0 of the fixed header to indicate the acks type. This frees the existing SubAck, UnsubAck, PubAck, PubRec, PubRel, PubComp, and PingResp packet codes for other uses. I feel this is a good approach and leaves room for future changes. I would invite others who may have thoughts along these lines to add their comments to the Jira. 6

7 Some General Goals of NAK Processing Addition of NAKs should preserve delivery guarantees Except a NAK means that at least once or exactly once delivery won t occur This is a change from MQTT but seems sensible. A NAK may create a hole or gap in the delivery sequence which was not possible in MQTT This is a new behavior. NAK acts like an ACK in QoS 1 and QoS 2 in the sense it frees the packet id, but unlike the ACK, message delivery to the topic does not occur. Don t alter existing behavior/mechanisms unnecessarily. Try to make forward progress to the degree possible rather than tearing down the transport connection for every problem. 7

8 QoS 0 : NAK responses to Publish Ambiguous QoS 0 NAKS can not be correlated with PUBLISHs because there is no packet id in QoS 0. Three options Prohibit NAKs at QoS 0 Allow NAKs even if ambiguous Devise another mechanism (e.g. add a packet id or other correlator) After discussion, I feel that NAKs are valuable diagnostics at QoS 0, even if they can t always be correlated with a PUBLISH. We solicit feedback from the TC on this topic. 8

9 QoS 1 NAK response to PUBLISH QoS 1 NAK seems simple at first, even with persistent sessions. But can a receiver first NAK then ACK the same message (transient error)? Seems desirable but can cause arbitrary reordering. 9

10 QoS 1 NAK response and re-ordering 10

11 Next Steps We continue to work on QoS 1 and QoS 2 Propose to consolidate MQTT-270 (Server-side disconnect) with MQTT-236 to provide DISCONNECT with error codes for both the server and client. This needs to be coordinated with the ACKs and NAKs. Goal is to have something written for the January meeting that is further developed and highlights open issues. Please provide any thoughts or suggestions you may have in the MQTT 236 JIRA. 11

12 Thank You! 12

Flow Control Issue 257. Ed Briggs August 11, 2016

Flow Control Issue 257. Ed Briggs August 11, 2016 Flow Control Issue 257 Ed Briggs August 11, 2016 1 Overview Purpose: review progress and discussions on flow control. I would like to thank Ian Craggs, Ken Borgendale, Andrew Banks, and Jonathan Levell