OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Preliminary minutes 11/11 teleconf

The prelim minutes for 11/11 teleconf are attached.

Please post any changes BEFORE Thursday PM of this week.

Tom Rutt
WSRM chair

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

Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Prelim Minutes WSRM TC Conference Call – Nov 11, 2003



The meeting of the WSRM TC took place by teleconference 
Tuesday Nov 11, from 5:30 to 6:30 PM Eastern Standard Time
(UTC - 5)
WSRM Meeting - Conference call Dial-in numbers:
Toll Free: 1-800-361-5659
International: 1-913 312 4155
Participant: 598997

0         Draft Agenda:

Draft Agenda to WSRM TC Conference Call – Nov 11, 2003

1 Roll Call (late arrival no longer counts by OASIS rules)

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes

3 Approval of Pending Resolutions

4 Discussions of Issues


1         Roll Call


First Name

Last Name




Voting Level





Booz Allen Hamilton






Cyclone Commerce






France Telecom

















TC Chair





































NEC Corporation






NEC Corporation






























Sun Microsystems






Sun Microsystems






University of Hong Kong










Meeting is quorate.

2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Doug agreed to take issue resolutions.


2.2      Approval of previous meeting minutes

Marc Goodner pointed out (by email)
The resolution for REL-32 in section 14.3 is incorrect. We started with the proposal from Iwasa, but as hinted at in the minutes rather than taking all seven definitions we agreed to only incorporate the first three on the RM-Reply patterns. The issue resolution however, is properly recorded in the current issues document
Alan stated we need to add that Bob had asked Alan to produce a white paper for the demo, and Alan agreed to do it.
Alan moved to accept f2f minutes with the above two clarifications, Marc G seconded, 
No opposition, October f2f minutes passed.
Regarding the 11/04 Minutes:
The meeting does not count for voting rights, due to a conference bridge problem which occurred at the last minute. Ben Block reported by email that he Joined the call after the Roll call, since he could not find the new number in time for the roll.
Marc G moved to accept the 11/04 minutes.  Bob seconded.
No opposition, 11/04 minutes approved.

3         Approval of Pending Resolutions

REL-31 Meaning of guarantee


REL-35 Header processing order


REL-38 Timestamp


REL-75 Meet Realization, R7.2 (multiple ack) requirement


Rel 94 Polling RM-Reply Pattern design


REL-100 Attachments


REL-32 Add new terms from requirements


REL-34  Figure 4 needs refinement



Marc g moved to accept all pending resolutions in the list above, Alan seconded.


No opposition. Rel 31, 35, 58,75, 94,100, 32, 24 are now accepted.


Action: Iwasa will incorporate resolutions into doc and Sunil will post the resulting schema on the site.


4         Discussion of Issues

4.1      Rel 50: Semantics of ExpiryTime:



Proposal From Jacques:


ExpiryTime indicates the ultimate date after which the receiver RMP will

not accept a message. In order to be accepted by an RMP, a message

must have schema-valid RM headers, and must not have expired.

Only accepted messages are subject to further processing by the RMP.


When receiving a message after its ExpiryTime date, an RMP MUST NOT accept the message.

Once a message has been accepted by the RMP, the fact that the message expires while

being processed by the RMP MUST NOT affect its processing, nor its final availability

status to the receiver application. Such expired messages must still be delivered to

the application, assuming they satisfy other reliability requirements.



Although ExpiryTime will not affect further the processing of accepted messages,

it is useful for an RMP to remember it in order to avoid unnecessary duplicate checks

with future messages, when "at most once" delivery is required.

Given the above definition of ExpiryTime, it is impossible that a received message M

accepted by the RMP, is a duplicate of past messages that are expired at the time M

was accepted.


Sunil raised a concern that the expiry time should be tied on being made available to user, rather than the last time to be considered by the RMP.


Sunil asked why not just use group expiry time, and get rid of expiry time for individual message.


Alan stated the delivery to the app is an implementation issue.


Sunil stated that we have three drop points: receipt, made available, taken up by app.


What is the point of just considering transport level.


Ordering is more than transport it is buffering.


Jacques and Alan stated that the contract is from RMP to RMP.


Bob Freund:  what is the purpose of expiry time?   TCP needs it to put an end to routing loops.  In our case, what scenario makes expiry time mandatory.


Jacques – expiry time is a transport qos, which the RMP has to honor.   Under normal conditions all message should have arrived by this time limit, if not, the transport is poor enough to consider the transport no longer valid.


Bob: your sender would know that it did not arrive if it did not get the ack.  How many bricks do we need to build the house, we do not need to put extra bricks on the house.


Jacques – this gives a clear semantic for duplicate elimination. 


Tom asked if we have a requirement in our requirements spec which led us to having the expiry time be mandatory.


Jacques: expiry time as a transport qos, other case totally eliminate.


Alan – qos parm to determine when link is so poor you want to know it.  It indicates there is a severe problem with end to end path.


Bob – but when that problem exists, the lack of acks will let them know.


Alan – if there is another way, I would have to think about it.


Jacques – just like we do not have ways to convey retry count.


Sunil: I do not want to be that drastic, to necessarily remove.  I see not having it as an extreme fallback case.  The semantics of expiry time change for singleton case and the group case.  I have concerns that if the message expiry time has an impact on the group expiry (T2 in Jacques proposal), it does not agree with rel 50. 


Doug: do you want consistent semantics about this parameter in all the cases.  Sunil – yes.


Jacques – the interpretation of expiry time as being a qos for the RMP can be seen as simplifying the protocol.


Sunil – we need to clarify semantics of expiry time.  Check twice, once when we receiver, later when we deliver.


Doug – my earlier concern on multiple checking was not for performance, my concern was that the second check dropping things would lead to the sender not knowing it was dropped.


Sunil: on sender side, the message should be kept until is is expired or until all preceding messages are acked it will not have surprises.  This can be enough.


Doug: if message 3 expires before message 2 is received, message 2 will never be acked.  Receiver must be bound to perform the delivery even if message 3 is expired. It should never check the expiry time after the first check on input.


Bob – in prior protocol work, the only time you introduce timeouts is when there is no other way out.  SNA CICS the app was responsible for providing the acknowledgement back.  Here we have the RMP, acting as a proxy for the application.  The fundamentals are to get to a fundamental state diagram on what the reliable transport looks like.   We have to understand from a state table view what this protocol looks at.  TCP put timeouts in for router loop avoidance.  We need to get down to a rock solid spec.


Tom: what about the group state removal based on a timer.


Bob:  if you have timers, the application designer should be involved.  We are getting a message from point A to point B, and to identify that the receiver has taken responsibility.


Jacques: either use expiry time as transport qos, or not use expiry time at all.  We need to continue this discussion on the mailing list.


Jacques: We need to discuss the deeper meaning of timing parameters.  The RMP needs to manage state associated with the protocol.  It is part of the protocol. 


Bob: we need to ensure we have protocol states which are fundamental for the operation of the protocol.  What does “make available to application” really mean.


Jacques – like retry interval, and max retry count, these are part of the protocol, but we do not communicate.  Some contracts are rmp to rmp, others are rmp to applications.  The contract needs to be clarified.


Jacques, we need a fundamental debate on this issue.


Bob, there might be reasons, but we have to go thru the engineering steps to justify their incorporation.


Jacques – I had done some work on the management of these states, and concerns have been raised.


What is the reasonable time for the transport to do its job.  This will help design the RMP configuration parameters.


Bob: well crafted state diagram will help.


Jacques; I tried this in the past, we can try again on email.


4.1      Rel 52: (New rules for persistence)(also, related "timing issues")



Proposal from Jacques:


Q1: When can a recipient "forget" about a sequence? How long must an out-of-order message

be stored prior to giving up on ever delivering it to the application?


Answer: see Rel57.


Q2: How do these time windows relate to the TTL (expiration) of an individual message?


Answer: see Rel50: ExpiryTime does not have any impact on the processing of a received message,

once accepted by the RMP.


Q3: Within what window will a duplicate be detected?


[Short Answer:] duplicates will be detected over all past non-expired messages.

Since by definition, messages that are expired when received will be rejected, there is

no risk ever to deliver two duplicates to the receiver application, as long as the ID of

non-expired messages (or ID intervals in the case of sequences) can be held in persistent store.


[Long answer]:


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 to the application (state: "available").

The general rule about message ID persistence, is that an RMP

MUST persist the ID of a message until the message expires.


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.


NOTE: Duplicate checks would be made over all past messages of the group, whether expired or not.

There is no added cost here, as these IDs are remembered as sequence number intervals.

The check will in fact be faster, as not discarding means fewer intervals.


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) below, it is not necessary to remember

the ExpiryTime of all messages of a group, as only the maximum of all ExpiryTime values

needs to be maintained.


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.

- Removal of the state of a group occurs either at termination time or later.

It means that all traces of the group (groupId, current sequence number, as well as

all received message IDs for the group as SequenceNumber intervals) are removed,

and therefore not available anymore for duplicate checks.


Termination (t1):

Triggering event: GroupExpiryTime is over.

Receiver side: The group is immediately terminated, and its state is removed from the RMP.

No duplicate check is done against that group ever. If a "late duplicate" arrives,

it would be automatically rejected due to its ExpiryTime, always earlier than GroupExpiryTime.

Sender side: The group is immediately terminated, and its state is removed from the RMP.


Termination (t2):

Triggering event: GroupMaxIdleTime is over.

Receiver side: The group is immediately terminated. But unlike (t1), some of its

past messages may not be expired yet. The RMP will keep the max of all ExpiryTimes

of messages received in the group.

The max(all ExpiryTime) will determine the date at which the state of the group is removed.

Sender side: GroupMaxIdleTime is counted between two sent messages. If it is over,

the group is immediately terminated, and its state is removed from the RMP.


Termination (t3):

Triggering event: the RMP receives a status="end" message. The group had either

GroupExpiryTime or GroupMaxIdleTime specified.

Note that this only tells us that "no greater seq number will be received after",

but that late messages may still arrive for this group.

Subcase t3.1: The group was complete on receiver side.

Receiver side: The group is immediately 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. If either ordered delivery

or guaranteed delivery was required, all Acks must have been received.

Then only the group is terminated.

Subcase t3.2: The group was not complete on receiver side.

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 t3.1: The group was complete on receiver side.

Receiver side: The group is immediately terminated. The date of removal of its state

is based on rules for (t2), using max(ExpiryTime) of all its messages.

Sender side: The group is also known to be complete. If either ordered delivery

or guaranteed delivery was required, all Acks must have been received.

Then only the group is terminated and its state removed.

Subcase t3.2: The group was not complete on receiver side.

The group is immediately terminated, and its state is removed from both RMPs.


There was no time to discuss Jacques proposal above.

4.2      Rel 57: Ordering and Missing Message Behavior



Proposal from Jacques:


[short answer]:

the RMP will wait until the sequence expires (indicated either by GroupExpiryTime,

or by MaxGroupIdleTime). All out-of-order messages will be then discarded.

However, even so storage resources may be insufficient to persist further out-of-order

messages. In that case, a resource fault (Fault code: "MessageStoreOverflow" will be

generated and made available to the Sender.


[long answer]:

Given the definition of Guaranteed Ordered Delivery, a message must not be delivered

to the receiver application if not all previous messages were.

Therefore in case a Receiver RMP decides to not wait any longer for a missing

message, the already received out-of-order messages MUST be discarded and not

delivered to the application.


Discarding an out-of-order group occurs in the following cases (d1, d2, d3):


Case d1: the group had GroupExpiryTime specified in its messages.

On the Receiver side, the out-of-order messages MUST be discarded as soon as this date

expires, and the group MUST be terminated. Indeed, any missing message received after

this date, will not be accepted by the RMP (as GroupExpiryTime is always greater than

ExpiryTime of any message in the group), and the group will never be complete.

On the Sender side,


Case d2: the group did not have GroupExpiryTime specified, but had GroupMaxIdleTime.

On the Receiver side, the out-of-order messages MUST be discarded if this maximum idle time

from the last received message expires, and the group MUST be terminated.


Case d3: neither GroupExpiryTime nor GroupMaxIdleTime were specified for messages

of this group. In this case, any out of order message will be discarded, and

the group immediately terminated.

NOTE: In order to avoid this situation, a Sender SHOULD either use time-based termination

criteria (like in d1, d2), or if not, SHOULD always wait for a message to be acknowledged,

before sending the next message in the sequence.

Tom: why not just send a fault for the out of order message, and still accept the earlier one when it comes.


Jacques;  we should take this to the email for debate, for we do not have enough time.


In all cases (d1, d2, d3), the Receiver RMP MUST generate an RM Fault "OutOfOrderSequenceExpired".

In case the Sender must take the initiative to poll for such a fault, it SHOULD do so when:

(1) some Acks are missing, (2) the group has expired according to GroupMaxIdleTime

or GroupExpiryTime, if these are specified.

Once the Fault has been obtained, the Sender MUST NOT send further messages for this group,

and MUST communicate instead a delivery failure to its application.


NOTE: the cases above (d1, d2, d3) decide of the discarding of out-of-order messages

of a group, and therefore of the termination of a failed ordered group.

This does not mean yet the removal of the group state, as message IDs may still be needed

for duplicate checks.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]