Rel 57 recommendation

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

Title: Rel 57 recommendation

I was supposed to send this before the meeting...(had an action item on Rel 57)
But felt there was enough already on the table for this call anyway...  so here it is.

Again, a bit verbose, but the proposal summary at the beginning is short enough and
should satisfy the superficial reader...

Jacques
<<Rel57-recommendation.txt>>

Rel57: proposal:

Title: Ordering and Missing Message Behavior Description: 
Split out from issue REL-16 
What is the behavior of a WSRM receiver that is ordering messages and one of the messages 
is never received, or at least not within the MET (timeout) of a subsequent message even 
though ACKing is being used?
For example: it receives msg #0, #1, #3. The MET for message #3 is 5 minutes so the receiver 
cannot wait more that 5 minutes for #2 to arrive. What does it do when the 5 minutes expires?

-----------------------------------------------------------------------
Patrick Yee  a preference for option (a) below.
26 Aug 2003: Doug mentioned one option for (c) -- silently dropping later messages. 
Have we previously discussed an issue that solves this problem?
See REL-86 for additional considerations. Proposal: Options:
(a) Send a fault back to the sender, notify the application, and abort all further ordering 
for the group.
(b) Send a fault back, deliver #3 to the app just before it times out, and continuing 
ordering all subsequent messages.
(c) Something else?


------------------ summary of proposal (Jacques) --------------------
So there are two questions to answer here:
Question (Q1): when to decide to give-up "waiting" for a missing message?
Question (Q2): which behavior should then be required: (a), (b) (c)?

Q1: A sequence is hopelessly broken when the minimum of {ExpiryTime of
each received out-of-order message } has expired. 
But storage shortage is also a valid cause that needs to be handled in spec,
if only on the fault side.

Q2: drop all out-of-order remaining messages, but send back a fault to Sender 
in all cases ((a) above).

-----------------------------------------------------------------------

NOTE: I use the term "mis-ordered" for messages that belongs to a sequence
which is supposed to be ordered but is not (un-ordered sequence now would
mean a sequence not supposed to be ordered in the first place).

NOTE: (a) is not quite clear: are the "mis-ordered" messages still delivered to the 
application?
I will assume :
(a1) keeps delivering without ordering anymore, 
(a2) drops all mis-ordered remaining messages,
and (c) is like (a2) but without sending fault back.


Question Q1: Proposal: A sequence is hopelessly broken when the minimum of {ExpiryTime of
each received mis-ordered message } has expired. 

Issue 1: 
For practical reasons, the sequence may be given-up earlier than the earliest ExpiryTime:
The receiver RMP might not be able to store a large number of mis-ordered messages 
if ExpiryTime is large (as it is usually based on business needs, not RMP capacity). 
In addition, as several mis-ordered sequences will compete for storage space, a "new"
mis-ordered sequence may have not much storage left and very quickly reach the store limit.
So there should be some means for an RMP implementation for deciding when to stop storing 
a mis-ordered sequence, which means "dropping" a mis-ordered sequence before ExpiryTime expires. 

Recommendation 1:
We will not fully address this issue here, as this may be seen as an implementation
issue, but an RMP implementation MUST gracefully detect and react to space
shortage for stored messages. (This may require some configuration parameter, e.g. storage
space, total number of messages, etc.)
Once the storage limit has been reached for a sequence, 
the Sender app will need be aware that the sequence is dropped. (this 
is addressed in Q2 below.)


Question Q2: Proposal: Since ordered delivery is strictly defined as "no message 
can be delivered to the application before all previously sent messages have been delivered", 
it appears that either (a2) or (c) is appropriate. Beyond these options, the proposal here 
is that the Sender application needs be made aware of the failure to deliver 
(or failure to make available) the rest of the sequence to the receiver application.

Recommendation 2.1:
Because "exactly once" delivery is also required, the Sender will normally receive Acks, 
and will notice that the "missing" message (say M1, the one that breaks the receiver sequence)
has failed. So a broken sequence will normally appear to the Sender RMP as (at least) a single
message delivery failure. This would work with both options (c) and (a2).
Note: several subsequent mis-ordered messages may be acked but not delivered to the 
application. The Sender application will however know that all these acked messages
were not delivered to its counterpart, because they belong to same GroupId as M1. 
So M1 delivery failure to the Sender app will also serve as a "sequence delivery failure". 

Issue 2:
As a consequence of the issue 1 in Q1, a mis-ordered sequence on receiver RMP can be
dropped before the earliest ExpiryTime expires. If we call M1 the missing message 
that "breaks" the sequence order, the Receiver RMP may actually have to dump the sequence
even before the resending mechanism of M1 is over. In other words, the sender may
finally succeed sending M1, get an ack for all the messages of its sequence,
and yet not know that half of the sequence was not delivered to the application.

Recommendation 2.2:
An explicit fault message to Sender RMP is the only sure way to warn of undelivered 
messages in the sequence. The RMP can then escalate the failure to the sender application.
Because an explicit fault is needed anyway from receiver RMP to sender RMP in order to
cover Issue 2, option (a2) is recommended here, as providing a uniform way to notify 
sequence failures.