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 1202 conf call

The prelim minutes are attached.

Please propose changes before Thurday PM.

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

Preliminary Minutes WSRM TC Conference Call – Dec 02, 2003



The meeting of the WSRM TC took place by teleconference 
Tuesday Dec 02, 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 Discussion of XML 2000 Demo

4 Discussions of Issues


1         Roll Call

First Name

Last Name




Voting Level





Booz Allen Hamilton






Choreology Ltd










TC Chair































NEC Corporation






NEC Corporation
























Sun Microsystems




Meeting is quorate.

2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Minutes  will serve for issue resolutions.

2.1      Approval of previous meeting minutes

Alan moved to accept the 11/25 minutes. Bob seconded.
no opposition, 11/25 minutes approved.

3         Discussion of XML 2003 Demo

Bob F stated he will work on the PR.


Alan did a white paper, Tom did an edit.


They will get together on Sunday in New jersey at a participant site.


Fujitsu has a suite if need for extended testing.


Bob: the demo is on the calendar of the xml 2003 web pages.


Bob: the information we gave them is available from the web site.  However it is not extensive.


Alan: concern, participants need to be made aware that the demo is happening.


Bob: I will check with Dee Shur


Bob: The white paper will be a handout available at the meeting.  Additional copies will be available.  There also will be a two screen presentation.


The white paper will be finalized by the subgroup.  The participants involved need to refine the white paper.


Tom might go as part of the demonstration.  


Tuesday afternoon in the demo.


Need to clarify we are doing CD .52.

4         Discussion of Issues

Iwasa is awaiting to put together a new document.

4.1      Rel 52 and 57 

The following is an email thread from Tuesday afternoon:

Jacques Durand wrote:


> Tom: inline <JD>



> -----Original Message-----

> From: Tom Rutt [mailto:tom@coastin.com]

> Sent: Tuesday, December 02, 2003 10:22 AM

> To: Sunil Kunisetty

> Cc: Jacques Durand; 'wsrm@lists.oasis-open.org'

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



> Sunil Kunisetty wrote:


> > >  Jacques,

> >

> >  Comments inlined  in red.

> >

> I have a few comments:


> Asuming we have the concept of group persistence control as an optional

> protocol feature, under

> control of the sender, I would like to proposed the following

> assumptions on the two

> group persistence control parameters:


> a) the First message in a group (the one with status=start) determines

> whether group pesistence control is in use for the group.

> - If the first message in the sequence of a group has neither group

> persistence parameter present, the group state will be removed upon the

> expiry of the last message received for the group.


No problems


> <JD> That seems to contradict termination case t4 in Rel52d proposal

> (is there anything wrong with it?).


Sorry, I meant to mean do t4.  A group without group termination parameters still has to reach

a termination criteria before the group deletion criteria can even be applied.


I attach a new state chart which shows these as two group states.



> I think you are talking of termination of a group here, not just the removal

> of its state (message IDs, etc.) which may occur later , due to future dup checks.

> If that is the case, I think that is way too strong: nothing should prevent a user to use a group

> for sending very sparse messages, e.g. one every day at noon.

> Yet you may want each message to have ExpiryTime of 30mn, because this is

> the max time a message should take to be transmitted under good enough conditions

> (if it takes more than 30mn, this is sign of a bad network, and RMP should reject it, fault it.)

> So all previous messages have expired when a new one comes in, but that

> is OK, the group should remain active.

> You may want later to terminate the group with an "end" marker,

> or even let the group active forever.

> Note that even when you terminate with an "end", we still need to keep group state

> until the max (ExpiryTime) has expired (not just the last message ExpiryTime)

> ExpiryTime should remain a notion orthogonal to the spacing between two messages,

> and in my opinion should not at all decide of the *termination* of a group.



> - If the first message has only one group persistence parameter present

> (either GroupExpiryTime, or groupMaxIdleDuration) then that will be the

> criteria used for destroying the group state.


> <JD> OK.


> - If the first message has both group persistence paramters present then

> both are in use, and the first to fire will determine when the group

> state is destroyed.


> <JD> We have to decide whether (a) it is as you describe, or (b) GroupExpiryTime

> takes precedance. Right now, the way Rel52 proposal is worded, and also

> the way Sunil understand it, this is (b). But I have no problem accepting(a).


If we do not take a) then we might as well not allow both termination criteria to be present for group. Lets decide at the meeting.

Sunil preference is to not allow both.  Use one or the other.  This simplifies the behaviour.


Bob: matter of prececence, since both have affect of extending group lifetime beyond expiry, having two criteria seem redundant.


Tom: it is the group lifetime beyond termination criteria, not beyond latest expiry.


Tom: there is also sending the end message to terminate.


> b)  Subsequent messages in the sequence do not need to repeat the group

> persistence paramters.  The sender will continue to used the latest

> received value for each parameter to serve as the triger for destroying

> the group state.


> <JD> OK, I think Sunil has worded this quite well in his previous email.

Sunil text will be looked at.


> c) In any subequent message either of the two (or both) which were

> present in the first message can be changed by sending a new value.  The

> new value for GroupExpiryTime can only be increased, while the new value

> for GroupMaxIdleDuration can be increased or decreased.

> <JD> I think this is beginning to be too complex and will trigger many tests.

> I thought we agreed at f-2-f that the first parameter value encountered was the right one,

> and subsequent messages should either have same, or nothing.

> I think Sunil also interpreted it that way (see his Monday email)


I think that if we have these group termination parameters, we might as well allow update.  The

attached state machine shows that this is not a great burden.

Option 1: only first message in group has parameters, subsequent not at all

              2 : first message has parameters, subsequent can change with latest taking precedence

              3 : first has parms, subsequent can increase the groupExiry time, or decreasing/increasing the maxIdleDuration.


Payrits: out of order can set another value

Tom: Always use latest one received.


Tom: as long as extended we will not have problems.


Max idle time shortening could be a problem.


Max Idle time can only increase.


Alan: they could be allowed to change, however put limit on frequency of change.


Sunil: this should be an implementation matter.


The receiver would have to deal with.


Tom: anyone for keeping it the same from beginning.  No response


Tom: Allowing increases in either parameter only.


On message 2 max idle, on 3, 10 hours, 


Tom: Can you change for a duplicate only sequence.


Tom: I am concerned about unordered sequence.


Bob: see if it represents a hazard.


Tom: can refine the state machine to not make it a problem for either ordered or unordered.


Tom: concensus that we, allow to change, strong recommendation that it not be done often.


Have threes state machines.


Payrits, could have sender state machine for group state.


Tom: I will take action to look into this.


Bob: see they get in the spec.


Alan: the should go into an annex or appendix.


The models can go in an annex later.


Timing example etc.


Tom will keep a running model document on the server.  The pdf version, the rose version if someone wants to edit it.


At some point we can move to place text from model into document.


Concensus to allow values to grow in a group.


Sunil: in unordered case do not need status = start.  We need to check on this.


Tom: would simplify to require for all sequences.  Let clarify that way.


Second issue: assuming the first is not received, what happens.


It could have a separate termination condition for either case.


Use t4 to terminate a not initated group.


Payrits: Mandate the expiry time, if send in first, always sent in every message for an unordered sequence.


Bob: since group expiry time is after message expiry.  The back fill should minimize problems.


Tom: Don’t put this requirement in unless we have to.   See if the state machine handles its.


For now wait to see if we need this requirements.


Tom Rutt


> The sender will

> know, when the receiver has acked the message which contains new group

> persistence parameter values present, that the reciever has knowledge of

> the new values.   If not acked, the sender can resend the group

> persistence parameters in a retry or in a subsequent message of the

> sequence.




> I agree with Sunil that we  have to agree on these asumptions (such as

> the above) before we can resolve the issue.


> Please comment if you do not agree with my assumptions above as an

> appropriate way forward.


> Tom Rutt


> Jacques Durand wrote:


> >>  inline:Note that unfortunately, I won't be on the call tomorrow...

> >> will be in a plane at that time :(But will have access to my email

> >> rest of week.Jacques

> >>

> >>     -----Original Message-----

> >>     *From:* Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]

> >>     *Sent:* Monday, December 01, 2003 6:14 PM

> >>     *To:* Jacques Durand

> >>     *Cc:* 'wsrm@lists.oasis-open.org'

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

> >>     >>

> >>

> >>      Jacques,

> >>

> >>      Few quick comments now. I'll do a more detailed review tomorrow

> >>     morning.

> >>

> >>      1) For Subcase t4.2, we need to propose the removal criteria. I

> >>     suggest:

> >>

> >>         / Subcase t4.2: The group was not complete on receiving side.

> >>     The group will be removed/

> >>     /     when the max(ExpiryTimes of individual msgs.) is met./

> >>     [Jacques Durand] Removal of group state is not same as

> >>     termination of the group: not sure which one you describe here. I

> >>     agree that your statement is good for removing the state, but

> >>     only  AFTER the decision to terminate the group has been made

> >>     (which is the main topic of Rel52). But as long as the group has

> >>     not been terminated, we should not even consider removing its

> >>     state. And here in t4.2, which could be an un-ordered group, I

> >>     still do not see any reason to terminate the group: expiration of

> >>     past messages is not a good reason!

> >>

> >

> >  My comment was specific to group removal as you already covered the

> > group termination part

> >  for t4.2 in your proposal. yes, group removal kicks in only after

> > group termination.

This is an editorial for Jacques proposal for 52.  NO opposition to this editorial


> >>     >>

> >>      2) Rel  57 is incomplete as it doesn't consider a case where

> >>     out-of-order/missing msgs. occur with

> >>          "status= 'end'" and GroupMaxIdleTime case.

> >>

> >>          Instead, we should enhance t5 and close Rel 57 as 'covered

> >>     by Rel 52'.

> >>     [Jacques Durand]  agee, they overlap. Should be merged.

Agreed to close rel 57 with a pointer to enhanced t5.


The expiry time must be less or equal to groupExpiryTime.  Send email about payrits concern.


> >>

> >>      3) Hence, t5 should be clarified & elaborated further.

> >>

> >>          Receiving side:

> >>          Triggering event for Termination: In an ordered group, a

> >>     message expires before delivery.

> >>          For state removal:

> >>             - If the group has a msg. with status='end', then removal

> >>     criteria as defined in t3 or t4 for

> >>               receving node will apply here also.

> >>             - If the group uses GroupExpiryTime, then removal

> >>     criteria as defined in t1 will apply.

> >>             - if the group uses GroupMaxIdleTime, then removal

> >>     criteria as defined in t2 will apply.

> >>

> >>          Sender Side: A non-acknowledged message expires on the

> >>     Sender side.

> >>           For state removal:

> >>             - If the group has a msg. with status='end', then removal

> >>     criteria as defined in t3 or t4 for

> >>               receiving node will apply here also.

> >>             - If the group uses GroupExpiryTime, then removal

> >>     criteria as defined in t1 will apply.

> >>             - if the group uses GroupMaxIdleTime, then removal

> >>     criteria as defined in t2 will apply.

> >>     [Jacques Durand] looks fine to me..


Agreed that Editing group should incorporate this proposal into a new editor’s draft.

> >>

> >>      4) We should also mention the following (I'm not sure whether

> >>     this is covered by this issue or not,

> >>           but we should definitely mention the following). Without

> >>     these conditions & assumptions,

> >>           following Rel 52 will be difficult.

> >>

> >>           - If the first msg. in a group (the msg. with

> >>     status='begin' or seq. no = 1) uses GroupExpiryTime,

> >>             then subsequent msgs.  in that group may or may not have

> >>     it. If exists, the value should be the same.

> >>             Subsequent messages in that group SHOULD not have

> >>     GroupMaxIdleTime.

> >>     [Jacques Durand] ok, I guess this "should not" is because

> >>     GroupExpiryTime always prevails.

> >>

> >  I believe this is what we finalized to make it simple.

> >

> >>     >>           - If the first msg. in a group (the msg. with

> >>     status='begin' or seq. no = 1) uses GroupMaxIdleTime,

> >>             then subsequent msgs.  in that group may or may not have

> >>     it.  If exists, the value should be the same.

> >>             Subsequent messages in that group SHOULD not have

> >>     GroupExpiryTime.

> >>           - All messages in a Group should have ExpiryTime. If the

> >>     group also uses MaxGroupExpiryTime,

> >>             then all individual message's ExpiryTimes should be less

> >>     than MaxGroupExpiryTime.

> >>     [Jacques Durand] OK,  but I think the "ExpiryTimes should be less

> >>     than ..." is actually a "MUST be less", because we count on this.

> >>

> >

> > yup.. replace shoulds with musts in the above sentence.

> >

> >>     >>           - ExpiryTime and MaxGroupExpiryTime are absolute timestamps.

> >>           - MaxGroupIdleTime is a relative one.

> >>

> >>         Did I get the above correctly? Did I miss any other

> >>     assumptions/conditions?

> >>     [Jacques Durand] that certainly completes usefully Rel52, 57.

> >>

> >>      -Sunil

> >>     >>

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

> >>>

> >>>------------------------------------------------------------------------

> >>>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.


> >>>




Proposals From Jacques mail:


Rel 57: (revision d) Ordering and Missing Message Behavior





[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.



Meeting wrapup:


Target to have entire proposal to resolve 52 and 57, including the state charts, ready by next meeting


Tom: Can Iwasa do proposed changes?  Iwasa, Yes, but I need some help.


Agreed to let Small editing group: sunil, tom, Iwasa, Jacques to work., andl propose a more compete proposal to vote at next teleconf in two weeks.  The discussion above should be used to produce this proposal.



No call next week.



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