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: Full Agenda for Teleconf

I attach the full agenda.

The latest mail in the Jacques, Sunil, Tom thread is attached, along 
with Jacques proposal "d".

I would like to discuss the issues using this email.

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

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

Meeting ?? quorate.

2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.


?? will take issue resolutions.

2.1      Approval of previous meeting minutes

xx moved to accept the 11/25 minutes. yy seconded.
?? opposition, 11/25 minutes ?approved.

3         Discussion of XML 2003 Demo


4         Discussion of Issues


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.


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


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


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


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.

> >

> >> >>

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

> >>

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

> >>

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



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