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

["Bob Freund" <Bob.Freund@hitachisoftware.com>]

Title: 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.  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.  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?

 

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.

 

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