Re: [wsrm] Rev "d" of Rel52, 57

[Tom Rutt <tom@coastin.com>]

Jacques Durand wrote:

> Rel52 and Rel57 reworded and adjusted to late comments, (tagged "rev d")
> though nothing radical:
>
> - Still makes use of Group termination timeouts:
>
I guess as long as the sender does not have to use the group termination 
timeouts I am happy.

However, we need to clarify that the receiver must be prepared to deal 
with them it it receives them.

Also the receiver must  be prepared to have them not be present for a group.

Tom Rutt
(as a member not chair)

>
> I  really find it hard to overload message ExpiryTime with group 
> termination
> semantics: ExpiryTime is about the delivery cycle for messages, which 
> is orthogonal
> to how long a group should be active.
>
> - Agree that ExpiryTime should be set, as Bob suggested, based on 
> expected
> transport performance and network monitoring (e.g. round-trip timing) 
> and should
> normally be opaque to users.
> It is a tuning parameter that says: "normally the delivery cycle 
> (transport + RMPs) for
> this message should not exceed this time. If it does, this means that 
> the communication
> conditions are too bad for doing reliable messaging.
> In that case the RMP will not deliver it, and notify the app instead."
>
> - Unlike ExpiryTime, group termination parameters have an application 
> semantics:
> In the same way a reliability QoS associated with a group is based on 
> application needs,
> (e.g. ordering), limit on group duration is also based on application 
> profiles:
> some apps will be able to mark the last message with "end", some will 
> not.
> Among these, some will be able to cap the duration of their groups 
> (GroupExpiryTime),
> some will only be able to say what idle time can safely be considered 
> as terminating
> a group (GroupMaxIdleTime). Finally, some groups are not supposed to 
> terminate ever...
> which is fine as long as an implementation can handle the space 
> overhead (group states)
> in case of many of these
>
> - So in Rel52 I still propose the 4 termination cases:
> They may not make for a concise spec, but they look very implementable 
> to me:
> in all cases, Sender and Receiver can synchronize group termination 
> without
> need of notification (thanks partially to the Ack semantics (Rel33)).
> To me this is by far the most important enhancement.
>
> Regards,
>
> Jacques
> <<Time-Rel57d.txt>> <<Time-Rel52d.txt>>
>
>------------------------------------------------------------------------
>
>
>Rel 57: (revision d) Ordering and Missing Message Behavior
>---------------------------------------
>
>Proposal:
>
>[notes from author: 
>- We also use GroupMaxIdleTime -if specified- for terminating an out-of-order sequence.
>- Discarding out-of-order messages of a group, and more generally terminating a 
>group, does not mean yet the removal of the group state, as message IDs may still 
>be needed for duplicate checks. See Rel52 for this.
>- The term "delivery" below has been precisely defined earlier.]
>
>
>On the Receiver side, as soon as either:
>(1) the earliest ExpiryTime of pending (stored) out-of-order messages has expired, or 
>(2) GroupMaxIdleTime has been specified, and has expired,
>all the pending and future out-of-order messages MUST NOT be delivered. 
>The RMP MUST terminate the out-of-order group as early as convenient after this date, 
>and out-of-order messages must be discarded. 
>
>On the Sender side, the RMP MUST terminate an ordered group as early as possible after
>one of these events occurs, whichever comes first:
>(1) a message for the group has not been acknowledged after all retries have
>been exhausted, plus a buffer time (e.g. retryinterval).
>(2) a message supposed to be sent or resent, has expired, and therefore will not
>be sent. 
>
>NOTE: On the Receiver side, out-of-order messages, although well-received, 
>will not be delivered and acknowledged before the sequence is complete, which may 
>trigger unncessary resending from the Sender. 
>The Sender MAY decide to NOT systematically resend a non-acknowledged message, 
>in case a previous message in the group has not yet been acknowledged. 
>
>
>  
>
>------------------------------------------------------------------------
>
>
>Rel 52: (revision d)(New rules for state persistence, also, related "timing issues") 
>-------
>
>
>General rule for persisting the ID of a message:
>---------------------------------------------
>
>The duplicate elimination feature requires persisting the message ID
>(GroupId and optionally the Sequence Number), after the message
>has been processed and delivered (made available) to the application.
>The general rule about message ID persistence, is that an RMP
>MUST persist the ID of a message at least until the message expires
>regardless whether the message has been delivered or not to the application.
>
>It is RECOMMENDED that an RMP removes the ID of a singleton message 
>(message with GroupId but no SequenceNumber) from its persistent store after it expires.
>However, unlike for singletons, it is RECOMMENDED to NOT remove the ID of a message that
>belongs to a non-singleton group, when the message expires. The reason is, message IDs
>for groups can be stored efficiently as intervals of integers.
>
>NOTE: When doing duplicate checks for messages of a group, there is no loss 
>of performance in checking over all past message IDs of the group, 
>whether expired or not. The check will in fact be faster, 
>because not discarding expired IDs means fewer intervals to look up.
>
>General rules for terminating a group, and for removing the state of a group:
>-----------------------------------------------------------------
>
>NOTE: these termination rules apply to both ordered and unordered groups.
>
>NOTE: In all termination cases (t1, t2, t3, t4, t5) below, it is not necessary to remember 
>the ExpiryTime of all messages of a group, as only the maximum of all ExpiryTime values 
>is needed.
>
>NOTE:Termination of a group, and removal of its state are two distinct events.
>- When a group terminates, both in sender and receiver, no message is expected to be
>sent or received for this group anymore. If a message is received after the
>termination of a group, with same GroupId as the terminated group, it is considered
>by the Receiver as belonging to a new group (the Receiver is not required
>to verify that a new GroupId value has not already been used in a previous group, 
>as this test is impractical).
>- When the state of a group is removed, any trace of the group (including status, groupId, 
>current sequence number, as well as all received message IDs for the group 
>e.g. SequenceNumber intervals) are removed, and therefore not available anymore for 
>duplicate checks. State removal may occur either at termination time or later,
>depending on the following rules. 
>
>
>Termination (t1): 
>----------------
>
>Triggering event: GroupExpiryTime is over.
>
>Receiver side: 
>The RMP MUST NOT accept any new message for this group and MUST
>terminate the group. It is RECOMMENDED that its state be removed as soon as possible.
>No duplicate check needs to be done against that group ever. If a "late duplicate" arrives,
>it would never be delivered to the next layer, as its ExpiryTime, which is always earlier 
>than GroupExpiryTime, would have expired.
>
>Sender side: 
>The group MUST be terminated, and its state removed from the RMP.
>
>
>Termination (t2): 
>-----------------
>
>Triggering event: GroupMaxIdleTime is over.
>
>Receiver side: 
>The group MUST be terminated. But unlike (t1), some of its past messages may not 
>have expired yet, and therefore their ID still be needed for duplicate checks. 
>If we define max(all ExpiryTime) as the max of all ExpiryTimes of messages already 
>received for a group, an RMP MUST persist the state of a group even after termination 
>of the group, at least until max(all ExpiryTime), in case duplicate elimination is required.
>
>Sender side: 
>The group MUST be terminated, and its state removed from the RMP when the time elapsed 
>since the last sent message (including retries) exceeds GroupMaxIdleTime.
>
>
>Termination (t3): 
>----------------
>
>Triggering event: the RMP receives a status="end" message. The group had either
>GroupExpiryTime or GroupMaxIdleTime specified.
>
>Subcase t3.1: The group was complete on receiver side. 
>
>Receiver side: 
>The group MUST be terminated. However, its state is removed according to (t1) or (t2), 
>depending which termination criterion was given.
>
>Sender side: 
>The group is also known to be complete, and MUST be terminated. 
>
>Subcase t3.2: The group was not complete on receiver side.
>Indeed, an "end" status only tells that "no greater seq number will ever be 
>received after", but late messages may still arrive for this group. 
> 
>Then the Receiver RMP and Sender RMP MUST apply rules of (t1) or (t2), 
>depending which one of GroupExpiryTime or GroupMaxIdleTime was specified.
>
>
>Termination (t4):
>----------------
> 
>Triggering event: the RMP receives a status="end" message. The group had neither
>GroupExpiryTime nor GroupMaxIdleTime specified.
>
>Subcase t4.1: The group was complete on receiver side. 
>
>Receiver side: 
>The group MUST be terminated. The time of removal of its state is based on rules for (t2).
>
>Sender side: 
>See subcase t3.1 above.
>
>Subcase t4.2: The group was not complete on receiver side. 
>Then the RMP should keep the group active: this event, by itself, does not cause the 
>termination of the group. 
>
>
>Termination (t5):
>----------------
> 
>Triggering event: In an ordered group, a message expires before delivery:
>Either the message expires in an out-of-order sequence on the Receiver side, 
>or a non-acknowledged message expires on the Sender side. 
>
>See Rel 57 for this case.
>
>  
>
>------------------------------------------------------------------------
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>


-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133