Title: Rev "d" of Rel52, 57
inline:
-----Original Message-----
From: Bob Freund
[mailto:]
Sent: Monday, December 01,
2003 3:14 PM
To: Jacques Durand;
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:]
Sent: Sunday, November 30, 2003
3:35 AM
To: ''
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>>
