[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: > Tom Rutt wrote: > Just a minor correction inline I just realized we also need to continue to require that the expriry time for each message in the group must be less than or equal to the latest GroupExpiryTime sent by the sender for that group. > > >> 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]