[Standards] Proposed XMPP Extension: Quality of Service

Peter Waher peterwaher at hotmail.com
Thu Dec 10 10:10:13 UTC 2015

Hello Dave
Thanks for your comments. I've responded to your concerns below:
> My initial reaction to this is that it's not providing anything beyond the
> state of the art, and it implies that <message/> delivery is highly
> unreliable (and suited to flood messaging), which is rather worrying. Not really. It's part of a mechanism called "reliable messaging", and is available for all sorts of protocols, even HTTP. (MQTT is mentioned in the proposal, but it definitely not limited to MQTT, it was just an example.) Reliable messaging is available in most protocols supporting queueing, where an item can only be delivered once, and exactly once (or, the sender receives a notification that it was not possible to deliver). It is used in cases where retries are not sufficient. This includes all non-idempotent actions, such as counting (including bank transactions) or accumulation, as opposed to absolute-valued information (such as set on/off, or set to N%) which are idempotent. All asynchronous communication protocols are somewhat unreliable, especially if clients have intermittent network connections. While its improbable that a client disconnects while a message is being transmitted, it can happen. And if many messages are sent, it finally will happen. > 
> I think XEP-0198 provides sufficient reliability to traffic that the
> additional overhead here is redundant, and we have XEP-0184 message
> acknowledgements to provide end-to-end acknowledgement, too. "sufficiently reliability" depends on use case, it's completely subjective. For chatting maybe. Not for monetary transactions. The proposal outlines a mechanism (taken from reliable messaging) that makes sure a message is delivered exactly once, or provides the client with information that it could not be delivered at all. Message delivery receipts defined in XEP-0184 is not sufficient either. First, it does not implement the "Exactly Once" level, which is also the most important, and the principal reason for writing the XEP. While it can be used for the acknowledged message case, It also has several weaknesses: One is that an acknowledgement is only requested. There's no mechanism the request is understood. So the message can be sent, parsed, body of message processed, but no acknowledgement returned, generating new requests, etc. To have a solution that either works or does not work, with no in-between state of working partially, you need to embed the message in another construct. If that construct is not understood, the entire message is discarded.
> If <iq/> is used, you'll always get at-least-once, no matter the support
> for 198 along the route. Correct. But it would be a proprietary, non-interoperable solution.
> To get exactly-once semantics, the protoXEP recommends the receiver has an
> infinite-sized store of previously received message identifiers - if the
> store ever expires old message ids, then it's potentially allowing multiple
> copies of the request to come through, which is (presumably) highly
> undesirable. No, it does not actually. See §5.2http://xmpp.org/extensions/inbox/qos.html#memory The point here is that if it cannot be received (at the moment) there's a clear error message returned, so the client is alerted. The state is never unknown. Furthermore, processed messages are forgotten, and the double request/response mechanism still makes sure the message is only delivered to the application layer only once.
> This could be avoided by having an if-not-modified-since semantic, which is
> very useful in other cases beyond simple 1:1 QoS. No, it would not work, since that would require the receiver to remember processed messages. The two-step transmission/delivery process, which is standard in reliable messaging, does not require the receiver to remember processed messages.
> Overall, considering the above, I'm inclined to push back until I've
> understood why existing methods are not suitable for the semantics this
> specification seeks to provide. I ask you to reconsider. The pattern described in this proposal conforms to common implementations of the reliable messaging Communication pattern, and is very useful, especially if you want to implement queueing and transaction support. (Reliable messaging comes with many names. Other popular names are Assured service, or Exactly Once delivery.)
> On 8 December 2015 at 17:40, XMPP Extensions Editor <editor at xmpp.org> wrote:
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Quality of Service
> >
> > Abstract: This specification describes a generic method whereby messages
> > can be sent between clients using a predefined Quality of Service level.
> >
> > URL: http://xmpp.org/extensions/inbox/qos.html
> >
> > The XMPP Council will decide in the next two weeks whether to accept this
> > proposal as an official XEP.
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20151210/58ae69e3/attachment.html>

More information about the Standards mailing list