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

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

I think that sooner or later we'll have to face the question of the precise semantics of our RM parameters.

 

Some have transport QoS semantics.

Clearly, parameters like "retry interval" and "retry count" are for managing transport problems: they say:

 

"our RMP is willing to make an effort up to this extent - but no more - in order to transmit the message successfully.

If that effort is not sufficient, our RMP will raise a red flag (a Fault), and conclude that something is wrong with

the transport. Making a greater effort is likely to be useless, and to degrade the performance of our RMP."

 

So I think these parameters should be adjusted based on reasonable expectation from the performance of the

transport layer, and also what the RMP is able to handle. It's RMP tuning... no application semantics.

The only sure guarantee we provide to the application, is a notification in case of failure, while trying

to reduce these cases of failure.

 

Some other parameters have clear application semantics, like GroupExpiryTime and MAxGroupIdleTime,

as the expected duration of a group,  or the time after which you can consider an inactive group is terminated,

obviously depend on the type of application that generate these messages. 

So I think of these parameters as under control of the apps (e.g. via RMP API).

 

Now we have ExpiryTime, which could very well have either transport QoS semantics, or application semantics...

(but not both)

 

1. transport QoS semantics: (latest time to reach the receiver RMP)

- most appropriate for expressing the expected level of transport QoS, as Alan suggests (though it should normally not clash

with retries, as a Sender should give-up retries as soon as ExpiryTime is reached)

- if we do that we'll have to explain better the capping with GroupExpiryTime (app-level)

 

2. app semantics: (latest time to deliver to app)

- makes it easier to deal with how long to keep an out-of-order sequence.

- but if it has app semantics, then has to be set by the application (how? is there alwaqys a business time limit?

is a Sender app expected to translate "business time" into clock time?

if a message has expired business-wise, is that a good enough reason to drop-it transport-wise?)

 

Even though that does not have to reflect in the spec, we need to make sure these parameters will

be meaningful to users in practice (how are they expected to set them?).

 

I'll send tomorrow another set of Rel50, 52, 57 adjusted for the app semantics of ExpiryTime,

to contrast with the previous set adjusted for transport semantics.

 

 Jacques

 -----Original Message-----
From: Alan Weissberger [mailto:ajwdct@technologist.com]
Sent: Sunday, November 16, 2003 7:41 PM
To: Jacques Durand; 'wsrm@lists.oasis-open.org'
Subject: Re: [wsrm] about ExpiryTime as "transport QoS"

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 <JDURAND@FSW.FUJITSU.COM>
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