[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Rev "d" of Rel52, 57
Tom Rutt wrote: Just a minor correction inline > 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. > - 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. > - 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. > > b) Subsequent messages in the sequence do not need to repeat the > group persistence paramters. The sender This should be "The Receiver RMP" > will continue to used the latest received value for each parameter to > serve as the triger for destroying the group state. > 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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]