Re: [wsrm] about ExpiryTime as "transport QoS"

["Alan Weissberger" <ajwdct@technologist.com>]

All

Not only do I agree with what Jacques says, but want to add that Expiry time detected at RMP receiver is an IMMEDIATE indication of some anomaly/problem with the communications faciltiy.  The retry counter at the transmitter, may not have reached terminal count (down count=0) when the receiver detects message has expired.  Hence, Expiry time could be a much faster indication of a network failure/fault.  I also think a Fault message should be sent back to sender when receiver detects Expiry time has elapsed.

 

alan

----- Original Message -----
From: Jacques Durand
Date: Tue, 11 Nov 2003 22:53:58 -0800
To: "''wsrm@lists.oasis-open.org''"
Subject: [wsrm] about ExpiryTime as "transport QoS"

I think a more precise semantics of the meaning of RM quantitative parameters
(not just ExpiryTime, but also retry-interval, retrycount...)
is overdue, and Bob had a good point on this.
(I'll address Sunil's issue in another mail) Let me try:

I'll start with an opening remark: if we don't use ExpiryTime,
why not also get rid of "retryCount" and just retry forever a failed message,
instead of deciding of an arbitrary number of times?

We all know the implicit answer, I believe, though it was never explicit in our spec:

We do expect in fact some minimal level of quality from the transport layer
(which includes intermediate nodes, etc). Why? because we simply consider
this level necessary for our RMP to do a good job.

This level is precisely measured by:
- decent number of retries (and retryintervals) that should be necessary
to get a message through (i.e. to the destination RMP).
- decent transport time necessary to get a message through (to other RMP)

If the transport can meet these reqs, then our RMPs can do their job in an optimal way.
If the transport cannot fulfill this contract, then we decide that getting our RMP
trying in spite of such failure would be counterproductive: instead, we prefer the RMP
to give-up and notify a failure to its application(s), which would then advise.

So yes, the choice of these parameters is arbitrary - i.e. our choice.
But they make sense with regard to good operating conditions for our RMP, which
in turn is necessary to serve the application layer well.

Resending forever a failed message would threaten the good operating conditions
our RMP needs (e.g. it could spend all its cycles just doing this if many msg failed .)
Just as accepting overly delayed messages would ignore unacceptable transport problems,
and also put undue burden on persistence and duplicate elimination.
So, detecting "bad transport conditions" and notifying the app layer, is also one form
of reliability.

(Note that ExpiryTime could be same for all messages, that simplification is not a problem
if we consider that the expected transport quality should be same for all messages.)

 Jacques

Alan Weissberger
2013 Acacia Ct
Santa Clara, CA 95050-3482
1 408 863 6042 voice
1 408 863 6099 fax