Comments <scott></scott> inline....
> -----Original Message-----
> From: iwasa [mailto:]
> Sent: Tuesday, July 29, 2003 5:10 AM
> To: wsrm
> Cc: iwasa;
> Subject: [wsrm] Rel16 Ordering and Sequencing
>
>
> 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 at section 2.4.
> --
> 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. (Please
> refer to section 3.3.2 for SequenceNumber element.)
>
> 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.
>
<scott>
Why are we requiring an ACK on ordered messages? Let's say I have a logging
application (like log4j) that simply logs all events sent to it. This is not
a critical app so if a message gets lost it is OK. But of the ones that are
successfully received, they should be kept in-order. So, no need to ACK, but
there is a need to order them. What is the behavior in this case of a
missing sequence #? Let's say the receiver receives #0,1,3. The receiver
delivers 0 and 1 to the app and hold #3 for its MET (msg expiration time),
waiting on message #2. If #2 does not show up within that time it delivers 3
and considers 2 to be lost.
</scott>
> 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,
> waste the message, and terminate this procedure.
> 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.
<scott>
I think the receiver must presist the message for at least the MET. If there
is a (local) "persistance duration" parameter and it wishes to persist
longer, that is implementation specific and should not be part of the wsrm
spec.
</scott>
> 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.
<scott>
See comment above on not requiring an ACK for ordered delivery.
</scott>
> 5. The receiver MUST remove the message if it was duplicating
> at #3 above, and terminate this procedure.
<scott>
Not sure what you mean by "terminate this procedure". If you are saying that
processing of messages within the Group is discontinued, I disagree with
that. If this is not what you mean, this needs to be clarified.
</scott>
> 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.
> --
<scott>
I propose that it follow the semantics of guaranteed delivery, if that is
requested in the wsrm header (through the ACKRequested element), otherwise
it continues on silently. I believe we should have guaranteed delivery
orthogonal to ordered delivery.
</scott>
>
> Please propose any updates to make the above
> sentences more appropriate.
> Thanks,
>
> Iwasa
>
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.ph
p
