RE: [wsrm] Rev "d" of Rel52, 57

[Jacques Durand <JDurand@fsw.fujitsu.com>]

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!

 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.
      - 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.
      - 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.