[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] Rev "d" of Rel52, 57
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?).
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).
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)
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]