[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=62238#comment-62238 ] 

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

In response to Ken's suggestion for a separate flow control mechanism, I have the following
thoughts:

0. Simplicity.  If a goal of QoS 0 is simplicity (fire and forget), and low protocol overhead, it seems adding two message types for QoS 0 flow control, and then having the API changed so that the client application would
receive an error (no buffers avail) or check (QoS 0 would block) seems rather complicated.  The proposed
behavior in the case that a client is unable to implement this sensibly, is to discard messages. This is
worse behavior than using TCP/IP flow control (silent message loss even in the absence of a transport error).

1. "Damage already done".  With a high latency channel. many messages may have been sent before
the destination can send a PAUSE, and it will take time for the PAUSE to arrive, so the damage may already be done. TCP/IP flow control seems to do a better job, and does so without loss.

1a. Postponement.  The PAUSE message can be delayed by an arbitrary time due to a) large PUBLISH message
going in the same direction, b) TCP flow control or retransmissions, TCP half-closed sessions etc. In this
case, the PAUSE is ineffective.

2.  By using different flow control mechanisms for QoS 0 and QoS>0, we will have two different MQTT flow
control mechanisms acting on the same control (ie. the ability to send}.  If these mechanisms disagree
with each other (which seems likely), it isn't clear what the behavior should be. This becomes even
more confusion when considering there is a 3rd flow control mechanism at work (TCP).

3. Purpose.  If the purpose of adding flow control is to limit the number of messages sent
when a client subscribes to a topic with many messages queued, or a client with many messages
buffered attaches to a server, then pause-resume with message discarding on over-run seems less
attractive than TCP/IP flow control.

So, perhaps, the TC might discuss the need for QoS 0 flow control in addition to TCP Flow control. If it's necessary, we should to have one flow control mechanism in one JIRA, IMHO.

> 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)