[Standards] Proposed XMPP Extension: Quality of Service

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


Hello Florian
 
Thanks for your comments. Please find my responses below:
 
> 
> ? 2.1 does not explain how "At most once" is enforced. I assume it
> requires support by the involved routing entities. But this means that
> you can't use it without ensuring that every involved routing entity
> supports it. I highly doubt that this will every be practicable. Or,
> using Matthew words: it opens a can of worms.
 
§2.1 describes "At most once" QoS level, which corresponds to a normal message. It's not different from any other message. You could say it's the default QoS level for messages in XMPP.
 

> 
> $ 2.2 duplicates Message Delivery Receipts (XEP-184).
 
Not really. As I mentioned to Dave, it is fail-safe, i.e. there's no inbetween state where the message might be processed but the receipt request not understood, etc. By embedding it in an IQ you make sure the message is only delivered if the QoS level is understood and processed.
 
Another difference is that the parsing of the QoS level is made at a lower level in the stack, as compared to the the parsing of the message, which would normally take place in the overlying application layer. The QoS level could thus be made transparant to the overlying application, and more fault-tolerant (also for applications which might become confused, depending on implementation). Also, there might be cases where XEP-0184 is counterproductive and in essence changes the meaning (semantics) of messages. Which might be undesireable.

> 
> ? 2.3 is AFAIK something no other XEP specifies and does *not* require
> support by the routing entities. 
 
Correct. Routing entities are not involved in this, only the original transmitter and final receiver that needs to understand the handshake.
 
> I would split the part off into a new
> XEP "Exactly Once Delivery" describing the double IQ process used. 
 
This is the principal point of this QoS XEP. The Acknowledged and Unacknowledged QoS services are available too. The unacknowledged service for purely pedagogical reasons, and the acknowledged service, for reasons explained above.
 
> Dave
> already mentioned that you run into issues because you theoretically
> need to keep the state forever
 
Dave was unfortunately wrong, see my response to his mail. You only need to remember the state of a message until you deliver it. That is the point using the double iq stanzas. The only thing an implementer needs to limit however, is storage capabilities and persistence of undelivered messages. That is left as an implementation specific detail, which does not concern the actual network communication.
 
> - the used ID and entity tuples to be
> precise - but I think something like that could be implemented in a
> sound and pragmatic way. The usefulness of "Exactly once" is, however, a
> different topic. Most distributed protocols rely on idempotent actions
> and therefore are happy with "At least once".
 
"Most" here, depends on use case. There's a reason why most bank transactions are done using other protocols. So, (as my aim here, se coming XEPs) is reliable messaging, queueing and transactions (including Micro transactions), a reliable messaging mechanism needs to be available in XMPP as well. It could be done in a proprietary fashion, but so can everything else too, and it would be counterproductive and contrary to interoperability.
 
PS: There's a common type of operations performed within industrial automation (and so IoT), that are not idempotent. They relate to counting (transactions) in that the report consumption or delta-values, rather than absolute values. Fine-grained control of a motor can often be done as "turn X degrees", where X might be counted in fractions of a degree. Receiving multiple messages by mistake would cause a state that the receiver cannot recover from. 
 
In general, any type of event that needs to be counted, are not idempotent.
 
I hope you reconsider and allow the QoS proposal to pass to the experimental stage.
 
Best regards,
Peter Waher
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20151210/60ed7658/attachment.html>


More information about the Standards mailing list