OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: about ExpiryTime as "transport QoS"

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]