From 2476089c80594662ddf4bfc341c0bb0f19af5bb6 Mon Sep 17 00:00:00 2001 From: "Matthew A. Miller" Date: Tue, 8 Dec 2015 10:09:28 -0700 Subject: [PATCH] ProtoXEP - Quality of Service (o.b.o Peter Waher) --- inbox/qos.xml | 427 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 427 insertions(+) create mode 100644 inbox/qos.xml diff --git a/inbox/qos.xml b/inbox/qos.xml new file mode 100644 index 00000000..1ad0e8bc --- /dev/null +++ b/inbox/qos.xml @@ -0,0 +1,427 @@ + + + %ents; +]> + + + +
+ Quality of Service + This specification describes a generic method whereby messages can be sent between clients using a predefined Quality of Service level. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0030 + XEP-0337 + + + + qos + &peterwaher; + + 0.0.1 + 2015-11-12 + pw + +

First draft.

+ + +
+ +

+ Sometimes it is important for the sender of a message to control the Quality of Service level (or QoS level) of the message. + In other protocols, such as queueing, such QoS levels are built into the protocol itself. XMPP lacks an intrinsic QoS level management feature, + which has left application developers to define proprietary solutions when such have been required. This document however, provides a generic + solution and can be combined with any type of message structure defined either proprietarily or in another XEP. + The handling of the Quality of Service level is done prior to parsing the contents of the message. It defines three generic + Quality of Service levels that can be used regardless of what type of message is being sent: +

+
+ +
Unacknowledged service - At most once
+
+

+ The message is sent at most once to its destination. The delivery of the message is not guaranteed. This QoS level + should only be used of the loss of messages is not critical to the application. +

+

+ Example: A sensor sending a stream of current values. If a value is lost might not matter much since the next message + provides a new current value, overriding any lost value. +

+
+ + +
Acknowledged service - At least once
+
+

+ The message is sent at least once to its destination. Sending of the message is repeated until message has been acknowledged. + It is not guaranteed that the message is delivered only once. Asynchronous conditions may arise where the message is delivered more + than once. If an acknowledgement is not received, at least the sender may become aware that the message was not delivered + properly. The At least once QoS level requires twice as many messages to be transported in the network as compared to + the At most once QoS level. +

+

+ Example: Any idempotent control action such as setting the light to a certain level. It is important that the control action + is received, but not how many of them are received. Any identical control action that follows makes no difference in output or + performance. +

+
+ + +
Assured service - Exactly once
+
+

+ The message is sent and delivered exactly once to its destination. The delivery of the message is divided into two acknowledged + message transfers. First, the message is transferred to the other side, but not parsed. The second operation, the message is requested + to be parsed and delivered. Both these steps are idempotent, making sure that the contents of the message is delivered exactly once. + If not possible to deliver the message, the sender will be made aware of this fact. The Exactly once QoS level requires + four times as many messages to be transported in the network as compared to the At most once QoS level and twice as many + messages to be transported as compared to the At least once QoS level. +

+

+ Example: Any control action or counting operation that is not idempotent, such as sending a control action when a button is + pressed, whenever an event has occurred or a transaction. If counting events, transactions, or accumulating consumption, it is + vital that messages are not processed twice, since it will change the end result. +

+
+ +
+ + + +

+ To send a message that is received at most once to its destination, a normal message stanza is used, as defined by the XMPP + protocol itself. The delivery of the message is not guaranteed. This QoS level should only be used of the loss of messages is not critical + to the application. +

+

+ Example: A sensor sending a stream of current values. If a value is lost might not matter much since the next message + provides a new current value, overriding any lost value. +

+ + + + + + + + + + ]]> + + + +

+ To send a message that is received at least once to its destination, an iq stanza of type set is sent containing an + acknowledged element from the "urn:xmpp:qos" namespace. The acknowledged element in turn contains the message to be delivered. + The iq stanza must have an id attribute that is used to identify if the stanza has been received or not. When an acknowledged + message is received, an empty response is returned to acknowledge the receipt. Parsing the message is done after sending the response. + If no response is received by the sending side within a given time frame, an number of retries should be made, using an interval or drop-off + algorithm. These time frames and number of attempts are implementation specific. +

+

+ It is not guaranteed that the message is delivered only once. Asynchronous conditions may arise where the message is delivered more + than once. If an acknowledgement is not received, at least the sender may become aware that the message was not delivered. + The At least once QoS level requires twice as many messages to be transported in the network as compared to + the At most once QoS level. +

+

+ Example: Any idempotent control action such as setting the light to a certain level. It is important that the control action + is received, but not how many of them are received. Any identical control action that follows makes no difference in output or + performance. +

+ + + + + + + + + + + + + ]]> + +

+ Note: The to and from attributes in the embedded message stanza are left empty. +

+ + +

+ To send a message that is received exactly once to its destination, an iq stanza of type set is sent containing an + assured element from the "urn:xmpp:qos" namespace. The assured element in turn contains the message to be delivered. + The iq stanza must have an id attribute that is used to identify if the stanza has been received or not, just as in the + acknowledged case. But to keep track of the message begin sent, a msgId attribute has to be provided as well. When an assured + message is received, a received response is returned to acknowledge the receipt. This received response echoes the msgId + attribute as well. But the message is not parsed and delivered at this point, only temporarily stored on the receiving end. + If multiple messages are received using the same msgId from the same sender, they are simply ignored, as one is already held in + memory. Still, the received response is returned as normal. +

+

+ When the sender receives the received response, it sends a new iq set stanza, this time with a deliver payload, + to tell the receiving end to parse and deliver the message, if in memory, and remove it from memory. The receiver acknowledges the message + by returning an empty iq result stanza. If receiving multiple requests using the same msgId, it will acknowledge each one. But + only one message will be parsed and delivered, as it will have been removed from the temporary storage on the receiving end. For both the + assured and deliver messages, a retry mechanism similar to the one used for acknowledged service is to be used. +

+

+ The Exactly once QoS level requires twice as many messages to be transported in the network as compared to the At least once + QoS level, and four times the number of messages as compared to the At most once QoS level. +

+

+ Example: Any control action or counting operation that is not idempotent, such as sending a control action when a button is + pressed, or whenever an event has occurred. If counting events, or accumulating consumption, it is vital that messages are not + processed twice, since it will change the end result. +

+ + + + + + Entered. + + + + + + + to='entrance@example.org/34892374'> + + + + + + + + + to='entrance@example.org/34892374'/> + + + ... + + + + + + Left. + + + + + + + to='exit@example.org/34892374'> + + + + + + + + + to='exit@example.org/34892374'/> + ]]> + +

+ Note: The to and from attributes in the embedded message stanza are left empty. +

+ + + +

+ If an entity supports signing forms as specified herein, it MUST advertise that fact by returning a feature of + "urn:xmpp:qos" in response to &xep0030; information requests. +

+ + + + ]]> + + + + + ... + + ... + + ]]> + +

+ In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, + presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities + information from an entity, it SHOULD use explicit service discovery instead. +

+ + + +

+ When sending messages using unacknowledged service, i.e. using the normal message stanza, it can be subject to offline message + storage if the recipient if offline. This might result in delivery of the message at a later time. +

+ + +

+ Message routing using unacknowledged service might be handled somewhat differently as compared to acknowledged and assured service, + since the first uses the message stanza and the latter two the iq stanza, which require a fill JID in order to reach its destination. + For consistency, full JIDs should be used also for unacknowledged messaging service, if possible. +

+ + +

+ If implementing support for this XEP, make sure implementation is generic and put on a lower level than other XEP-specific processing + of incoming stanzas. Messages received using this server should be fed into the normal message processing and handling after the QoS level + has been ascertained. This makes it possible to use QoS levels for any type of message being sent and received. +

+ + +

+ One decision each implementation of assured QoS has to make, is where to persist incoming messages between reception of message and + the delivery to underlying message processing logic. Should they be persisted in internal memory, persistent Flash/EEProm, as local files + or in a database? Such implementation specific concerns are left to the implementor, as this XEP only concerns itself with the communication + layer between parties. But the choice of solution might affect to what level a message is ascertained to be delivered: Will delivery be + guaranteed, even beyond a system reset at the receiving end? Or a system reset at the sending side? If delivery of the message has to be + ascertained even if a system reset at the sending side is allowed, persistance of the request must also be made on the sending side. + (To some extent, this latter concern even affects acknowledged service.) +

+ + +

+ Outstanding message IDs used in assured delivery, must be unique for the sender (counting the Full JID as the sender). If running + short on Message IDs, such can be reclaimed after the receipt of a successful delivery of a previous message. Message IDs can be + sequence numbers, or hash values of the contents of the message. +

+ + + + +

+ The to and from attributes of embedded message elements should be ignored and left out by the sender, except in the case of + unacknowledged service, where the message element is the message stanza itself. In the case of acknowledged and assured quality of + service levels, the message element MUST have its to and from attributes overwritten by the corresponding attributes of the iq + stanza being used. This, to avoid the injection of messages with unauthenticated and unauthorized identities. +

+ + +

+ As incoming message using the assured quality of service level is temporarily stored on the receiving end, the receiver might become + vulnerable to memory attacks if not implementing some basic counter measures: +

+
    +
  1. +

    + Do not accept messages using assured service from untrusted sources, for instance from MUC rooms or senders not in the + roster. If deemed untrusted, an iq error of type not-allowed should be returned instead of the + received element expected in normal flow. +

    +
    2. +
  2. +

    + Set a limit on the number and size of assured messages that can be simultaneously received from a single source. If a source + sends more than this, the resource-constraint error should be returned instead of accepting the message. +

    +
    3. +
  3. +

    + Set a total limit on the number and size of assured messages that can be simultaneously received from all sources. If anybody + sends a message that will exceed this amount, the resource-constraint error should be returned instead of + accepting the message. +

    +
    4. +
+

+ Whenever invalid use of the assured messaging service is detected, wether it be from untrusted sources or spam, an event should be + logged using &xep0337; so that the source of the error can be found and appropriate counter measures taken. +

+ + + +

This document requires no interaction with &IANA;.

+ + +

+ The protocol schema needs to be added to the list of XMPP protocol schemas. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]]> + + + \ No newline at end of file