Rel 102

[Jun Tatemura <tatemura@ccrl.sj.nec.com>]

REL-102 Termination of Receiver persistence requirements

I propose to remove the following requirement, which is considerd too
strong.

 > When supporting Guaranteed Message Ordering, the receiver is
 > REQUIRED to persist out of order messages until one of the following
 > conditions are met:
 > * Receipt of all previous messages and successful invocation of the
 >   deliver operation.
 > * The span of time indicated by the ExpiryTime element has expired.

The receiver does not have to have any responsibility on an undelivered
message even it has been received. The sender takes the persistence
responsibility of the message until it receives the acknowledgment or
the message is expired. The receiver can wait for the sender's retry
if it throws away an undelivered message. The receiver persists out of
order messages only for performance improvement. In some cases it is
good for performance (availability) to throw away out of order
messages (see [*1] below for details). I would like to let implementers
optimize it.

All the receiver needs to persist is the group information
(groupExpiryTime, maxIdleDuration, and message id of the delivered
message with the maximum sequence number)
until it is terminated.

For duplicate elimination, I agree with Jaques saying that
 > When duplicate elimination is requested, the Receiver rmp is required
 > to persist message IDs of delivered messages until they are expired.


If agreed, two more issues can be closed as follows:

REL-106 Group termination after delivery
(Should a reciever only update group termination value for messages 
which are delivered?)

Answer is Yes.
Since the receiver does not have to persist out of order messages,
it is not a good idea to let the behavior depend on unreliable data
(i.e. undelivered messages). Thus, group termination value should not
be updated with undelivered messages. This decision will make the 
receiver's behavior more predictable for the sender.


REL-86 Unordered messages window size parameter

We do not need an agreement parameter on the window size.
The receiver can decide any unordered messages window size parameter
without any aggreement with a sender RMP or a reveiver application.

-------

[*1]
When the memory size is limited, the receiver may want to drop a
received (but undelivered) message in order to receive a new
message.

Here is an extreme case: A sender can send, mistakenly or intentionally,
a large number of unorderd messages. It will soon fill up the available
memory of the receiver and make the service unavailable for other
senders. The receiver need to wait for message expiration which may be
set very long.
In such cases, a sophisticated receiver implementation may want to set a
window size for each message group. By dropping a message which sequence
number is larger than (window_size + max_sequence_no_of_delivered), the
receiver can improve its availability.

Some receiver implementation may want the window size to be zero,
meaning that an unordered message is thrown away immediately.
The ordered delivery guarantee still works.

------------------------------
Jun Tatemura