RE: Rel 102

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:]

Sent: Friday, January 16, 2004 6:43 PM

To: ''

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