RE: Rel 102

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: RE: Rel 102

I think Jun has a point:
Every requirement for persistence is conditioned by space availability,
and cannot always be honored, or should not always be honored
by a sound memory (as well as performance, security) management.

Guaranteed ordered delivery as we defined it is about:
(a) guarantee that all previous messages have been delivered when delivering M,
(b) receiver making a reasonable effort in re-ordering out-of-order messages.

While we must commit on (a), the requirement (REL-102) challenged by Jun
is in fact the maximum that a receiver can do to support (b), but is not
always implementable due to limited persistence, performance and security issues.
On the "minimum" side, the lazy approach Jun describes for (b)(just rely on
intertwined "retries" to get the order right) has its merits too. 

As the maximum effort for (b) cannot always be implemented,
then an agreement about (b) would require quantitative parameters
(e.g. re-ordering window size, expected message size...) that so far
we consider out of scope for 1.0., (Rel-86 to be closed without action)
as they would require more comprehensive RMP memory management parameters
(if window size, how many concurent groups can be handled? for which size of payloads?)

So it appears to me that this requirement should be at best an implementation note.
The only requirements the spec can make here are about:
- (a) above.
- that both sender and receiver detect the case where a sequence is
hopelessly broken due to expiration of undelivered messages.
(Already required by Group Termination case #5).

Incidentally, I think we need to say a few words on how ExpiryTime should be set,
as it plays an important tuning role for all features (Guaranteed delivery,
message ordering features, duplicate elimination).
ExpiryTime should not be set to arbitrary future dates, has NO "application semantics"
e.g. purchase order expiration, but instead has "network semantics" :
reflects the time by which a message is expected to be delivered under
normal network conditions, and beyond which it is considered counterproductive
for RMPs to keep trying.

Jacques

-----Original Message-----
From: Jun Tatemura [mailto:tatemura@ccrl.sj.nec.com]
Sent: Friday, January 16, 2004 6:43 PM
To: 'wsrm@lists.oasis-open.org'
Cc: Jacques Durand
Subject: Rel 102

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