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:]
>>> *Sent:* Monday, December 01, 2003 6:14 PM
>>> *To:* Jacques Durand
>>> *Cc:* ''
>>> *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: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
