[OASIS Issue Tracker] (MQTT-257) Flow Control

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

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

Ed Briggs commented on MQTT-257:
--------------------------------

I've added a short document describing the use of the send window to implement flow control. The document describes some characteristics of the approach, and establishes the upper bounds on mean throughput for QoS 1 and QoS 2 messages using this approach. 

Discussion: Issue 257 Flow Control: Max Send Window.

https://www.oasis-open.org/apps/org/workgroup/mqtt/document.php?document_id=57764

This builds upon Ian Craggs' document referred to in the previous comment.

This document was presented in MQTT-TC meeting on March 17, 2016, followed by a brief discussion.  The comments I captured were as follows:

Ken Borgendale advises that delaying ACKs has resulted in difficulties and would be better avoided, and that the send window credit mechanism would be preferable.    He adds that since this approach does not work with QoS 0, it might be useful to add another mechanism for QoS 0, such as a pause/resume message.  Also, a disconnect message might be used to signal flow control violations.

Andrew Banks suggested that QoS 0 could be handled using the existing TCP/IP flow control by simply not posting receives thereby applying back-pressure to the sender.

> Flow Control
> ------------
>
>                 Key: MQTT-257
>                 URL: https://issues.oasis-open.org/browse/MQTT-257
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: futures
>            Reporter: Peter Niblett
>
> Developers sometimes ask if there's a way to slow down an MQTT message sender to stop it sending PUBLISH packets faster than the receiver (be it a server or client) is able to process them.
> The receiver can apply back pressure at the TCP/IP level (if it's a TCP/IP transport) or - for QOS 1 and QOS2 - it can delay sending acks so that eventually the sender's inflight message window will fill up, but these mechanisms are a bit crude, and the receiver has no in-band way of letting the sender know what rate is acceptable to it. 
> We need to decide whether this is a problem that affects a significant number of existing or envisaged real-life applications (as opposed to performance and stress tests)



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