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