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

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

Title: Rev "d" of Rel52, 57

inline:

-----Original Message-----
From: Bob Freund [mailto:Bob.Freund@hitachisoftware.com]
Sent: Monday, December 01, 2003 3:14 PM
To: Jacques Durand; wsrm@lists.oasis-open.org
Subject: RE: [wsrm] Rev "d" of Rel52, 57

A few comments:

 

ExpiryTime: The sender's bid for a time beyond which there is no need to persist the message. 
[Jacques Durand] yes, that is implied by Rel50 resolution, but Rel50 is stronger: expired message must NOT even be delivered to next layer (it is not like the RMP is free to do as it likes).

 

 Receivers that cannot honor this request must fault. Note that for messages contained in a group, any rmp state related to groups must be held at least as long as there exists an unexpired message.

GroupEnd: a marker with application semantics ONLY which may usefully signify a conceptual end of file.  It serves no fundamental protocol role other than it may be used by implementers as a hint for optimization purposes.

 

GroupID: An identifier that may be used by the application to identify a collection of messages.

 

RemoveAfter: Since RemoveAfter must be set equal to or larger than ExpiryTime, it only serves the function of extending the lifetime of group information that may be held in the RMP even though all prior messages in the group have expired.  
 Since it is an optional attribute, then receivers must in any case implement a policy-driven mechanism that gracefully terminates a group after all messages expire. 
[Jacques Durand] You seem to imply that without RemoveAfter, group should be terminated when its messages expire. I believe this is the real contentious point: in the absence of RemoveAfter (renamed GroupExpiryTime), I believe the group should not be terminated just because all of its previous messages have expired: it is OK to send new messages after that. In fact, it is OK to have some never-ending groups, if that is what users want. And this, independently from each message expiration time.

 

 

 In the case of many concurrent groups with large RemoveAfter times, implementers will be forced to implement another policy based mechanism to prevent group information from growing without bounds.  Since these two mechanisms must exist then RemoveAfter has the role of requesting resources that potentially the receiver does not have.  Of course this case dictates the introduction of another fault.  Perhaps this is just the point.  Without this optional attribute in an incoming group header, the group must function anyway.  Is the juice worth the squeeze?
 
[Jacques Durand] We could of course let the RMP utilize resources until a storage fault is generated, and not bother about providing ways to apps to remove useless states. But we already provide some control to apps, with the "end" marker. I see GroupExpiryTime and GroupMaxIdleTime as just other (optional) ways. Apps don't always know when a message is last one for a group, at the time they send it. 

 

 

RetryInterval: The time, that a sender waits before re-transmitting an unacknowledged message.  There is no protocol relevance to this parameter other than to avoid anomalous behavior, the Retryinterval must be longer than the round-trip message time and much shorter by factors than ExpiryTime-NOW.  The sender may calculate this parameter from observed network and receiver behavior in the manner similar to that described in TCP Extensions.

 

Security/Robustness:

Receivers shall continue to operate with respect to normal operation even though one or more senders may be hitting it with bad parameters.  This I presume would be extra-important for any protocol describing itself as reliable. Consider varying values of every parameter in message re-tries and near infinite expiryTime and RemoveAfter. 

 

Ramble:

Proper protocol operation, I assume, must occur even with a dormant or inactive application.  That means that typically the RMP's persistence mechanism thus will operate as a queue of messages waiting to be processed by the application.  That makes us look for ways to reduce state and state persistence for the sake of efficiency.  We have not discussed application to RMP interactions which may be useful to implementers.  There are a number of potential optimizations (such as, message payloads may be deleted for any message that has been acted upon by the application), but they have no bearing on the protocol specification since they relate to APIs which are not part of the specification.  I am feeling that RemoveAfter and its cousin MaxGroupIdle fall in the category of implementation optimization hints as well.
[Jacques Durand] For me, they fall in same category as the "end" marker for terminating a group: an app convenience. Because again I think you can't rely on message expiry time to terminate a group.

 

-bob

-----Original Message-----
From: Jacques Durand [mailto:JDurand@fsw.fujitsu.com]
Sent: Sunday, November 30, 2003 3:35 AM
To: 'wsrm@lists.oasis-open.org'
Subject: [wsrm] Rev "d" of Rel52, 57

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.
[<Bob Freund>] My comment was related to message retry interval.  that is the amount of time that a sender should wait prior to re-transmission of an unacknowledged message.  Round trip timing is most important for this parameter. 

[<Bob Freund>] ExpiryTime should be the time after which a message in persistent storage may be deleted
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>>