Proposed resolution for Rel16 - Ordering and Sequencing

["iwasa" <kiwasa@jp.fujitsu.com>]

Since we have decided in the last telecon to mandate both 
AckRequested element and DuplicateElimination element
for Ordered delivery, I would like to propose the same 
resolution I sent out before as follows:

--
Here is a proposed resolution for Rel16,
which is my action item at last telecon.

--
Issues:
Description: The behavioral semantics of senders and receivers need to be
further defined with regard to the tracking of sequence numbers for the
purpose of detecting duplicate or out of order messages. For example: How
long should a receiver hold on to out-of-sequence messages in anticipation
of a missing message?"
REL-11 proposals address some of the sequencing issue.
REL-6 and REL-17 deal with persistance issues, but not out of sequence
messages directly.
[see original spec]
--

Proposed resolution:
Include the following description to the spec.
--
When a sender sends multiple messages with Guranteed message ordering,
the sender is REQUIRED to include MessageOrder element in the message.
And all messages to be delivered in order MUST have same GroupID
and MUST have sequence number as a value of SequenceNumber element
in order of the message to be delivered to receiver's application.

When the sender uses Guranteed message ordering,
the sender MUST use Guaranteed message delivery and Guranteed
duplicate elimination together. In detail, the sender MUST include both
AckRequested element and DuplicateElimination element, as well as
the MessageOrder element for Guranteed message ordering.

A receiver that received messages including MessageOrder element
MUST provide its application layer with those messages
in order within the same groupID. In detail, the receiver MUST
follow the following procedure, when it received messages
with MessageOrder element:
1. Confirm the message is including AckRequested element and
    DuplicateElimination element as well as MessageOrder element.
    If there is missing eaither/both of the above two elements,
    the receiver MUST send back [TBD] Fault message to the sender,
    and waste the message.
2. The receiver MUST check if the message is duplicating
    with any message persisted at receiver.
3. The receiver MUST persist the message until PersistentDuration
    [TBD:This parameter must be defined as a configuration parameter]
    has expired, if the message is not duplicating.
4. The receiver MUST generate and send back an Acknowledgement
    message to the sender. Note the Acknowledgement message
    MUST be sent back whether it was duplicated or not.
5. The receiver MUST remove the message if it was duplicating
    at #3 above.
6. The receiver MUST check the SequenceNumber and GroupId
    to see whether the message is arrived in order within the GroupId.
    If the message is arrived in order, the receiver MUST provide the
    message to the application layer. If the message is not arrived
    in order, the receiver MUST wait until all previous messages
    is received by receiver and provided to the application layer
    in order.

In addition to the above procedure, the receiver MUST check
messages persisted and didn't provided to the application layer
until PersistentDuration is expired. If there are those messages,
the receiver MUST send back [TBD] fault to sender to notify
those messages are not delivered to the application, even if
the Acknowledgement messages were returned before. And
then the receiver MAY remove those messages.
--

Thanks,

Iwasa