[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Rev "d" of Rel52, 57
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. > > >>> > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]