ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] Issue i022, RM Assertions
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: "Bob Freund" <bob.freund@hitachisoftware.com>
- Date: Thu, 20 Oct 2005 15:58:34 -0400
+1,
However, I am not certain that we need
to add anything to the base spec.
Cheers,
Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295
"Bob Freund" <bob.freund@hitachisoftware.com>
wrote on 10/20/2005 03:12:58 PM:
> Vikas,
> I don’t think that these parameters have much
to do with traditional
> flow control, just the re-try behaviors of each end.
> The delay times and intervals are not interoperability
concerns as
> much as they are path and performance optimizations.
> Flow control, if I understand you correctly,
is something like the
> sdlc mechanism of rr/rnr whereby the sender could ask if the
> receiver was ready to receive a message or not. This tends to
be
> part of much lower level protocols involving physical transport.
> The spec assumes that there is some sort of transport underneath
> that has the responsibility of managing what one might call (to coin
> a term) the link layer or transport layer.
> This protocol depends on retry to achieve reliability,
but the
> timing characteristics have the only impact of swamping the channel
> if too short and reducing errpr recovery and thus performance if too
long.
> Even with negotiated algorithms, it is not predictable
what the
> error rates on the channels might be. Oftentimes, errors are
bursty
> and what works very well under normal circumstances will fail during
> a burst. This what we applied in the discussion leading to RFC1323
>
> No, I believe that the parameters BaseRetransmission,
> ExponentialBackoff and AcknowledgementInterval all need to be
> removed, but a discussion of retransmission should be added to the
> base spec, otherwise, we don’t have a reliability protocol.
>
> Thanks
> -bob
>
>
> From: Vikas Deolaliker [mailto:vikas@sonoasystems.com]
> Sent: Thursday, October 20, 2005 1:58 PM
> To: Bob Freund; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Issue i022, RM Assertions
>
> Bob,
>
> I agree with you in so far as implementers will
implement flow
> control in ways suitable for them. Ideally, what is needed is a
> mechanism for the RMS and RMD to negotiate and agree upon a flow
> control algorithm. Part of this negotiation would entail exchange
of
> schema related to parameters necessary to follow the algorithm.
> Should such a mechanism be created by this WG, it should then be
> part of the core reliable messaging protocol and not in the assertions
model.
>
> Vikas
>
>
>
> From: Bob Freund [mailto:bob.freund@hitachisoftware.com]
> Sent: Thursday, September 22, 2005 7:26 AM
> To: vikas@sonoasystems.com; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Issue i022, RM Assertions
>
> Retransmission parameters as well as algorithms
are problematic for
> the following reasons:
> 1) The characteristics of
the path from source to destination
> are often unknown and often are time-variant.
> 2) 2) Retransmissions if
too frequent cause flooding and
> potential catastrophic degradation if the path is near saturation
> 3) The Path may consist
of not only transmission means, but
> also intermediaries with attendant processing delays
> 4) Exponential backoff may
be implemented many ways, there is
> more than one algorithm any they have different parameters
> 5) Backoff algorithm selection
may be implementation specific,
> what is good for cell phones may not be good for cluster interconnected
nodes
> 6) I have found no theoretical
modeling available of the case
> of web services cum intermediaries
> 7) Most published data concerning
the behavior of backoff
> algorithms examine fairly simple network segment related saturation
> and do not address client, server, let alone intermediary saturation.
> 8) Exponential backoff algorithms
need a recovery mechanism
> for those situations where there is a high standard deviation of delay.
> 9) TCP/IP experience has
shown that efficiencies are improved
> with an adaptive mechanism as described in TCP Extensions for High
> Performance (see RFC 1323 RTTM)
> Proposal:
> Clearly a backoff mechanism is required; however
implementation
> specific needs are not served well by the selection of any specific
> algorithm for all potential implementations of this specification.
> It is recommended that implementers utilizing IP based transmission
> media consider the mechanism described in RFC 1323. Delete all
re-
> transmission parameters as described in the specification since they
> are unnecessary and unhelpful should the implementer use an
> algorithm with a different set of controls.
> Thanks
> -bob
>
>
> From: Vikas Deolaliker [mailto:vikas@sonoasystems.com]
> Sent: Thursday, August 04, 2005 9:53 AM
> To: ws-rx@lists.oasis-open.org
> Subject: [ws-rx] Issue i022, RM Assertions
>
> Description:
> (revised)
>
> The RM policy assertions, specifically, InActivityTimeout,
> BaseRetransmissionInterval and ExponentialBackoff parameters need
to
> be more finely specified.
>
> The following are the areas which need finer
specification
>
> a) Default Value for InActivityTimeout,
BaseRetransmissionInterval
> and ExponentialBackoff:
> There needs to be a default set for these parameters.
Currently the
> specification says “If omitted, there is no implied value.” Since
> these parameters dictate the delivery of the message, an
> implementation is going to assume a default anyways. Not specifying
> this will make implementations assume a different default value and
> cause unwanted timeouts.
>
> b) Definition of InActivity
> There needs to be a discussion of definition
of inactivity. If RMS
> sends a sequence to RMD and is waiting for the response which is
> delayed for whatever reason, is that inactivity on the link between
> RMS and RMD counted towards InActivityTimeout? If yes, then it is
> entirely possible that while waiting for a sequence response, RMS
> could timeout due to InActivity.
>
> c) Applicability of InActivityTimeout:
> It needs to be specified to which end this parameter
is applicable.
> It seems like sequence creator starts the timer for
> InActivityTimeout. If the intention is that this timer exists on
> both ends of a sender and receiver engaged in a RM sequence, we need
> to define a method for synchronization of the timer value of this
> parameter between them. For example an KeepAlive message would need
> to be defined for keeping sequence alive.
>
> d) Corner Case Handling:
> There needs to be a discussion of the corner
case when the
> BaseRetransmissionInterval exceeds InActivityTimeout. This can
> happen when the RMD is indisposed and ExponentialBackoff drives up
> the value of BaseRetransmissionInterval. In this case my
> retransmission is schedule later than the timeout that I need to
> abide to. What state does the RMS enter in this situation?
>
> e) BaseRetransmissionInterval Needs an
Upper Bound:
> If an RMD is offline for extended period of time,
one can expect the
> BaseRetransmissionInterval to be exponentially backed off i.e.
> become large enough to be not meaningful anymore. Having an upper
> bound on this parameter will enable the RMS to stop retransmitting
> and report a fault.
>
>
> Proposal:
> (revised)
>
> 1) InActivityTimeout and BaseRetransmissionInterval
can be merged
> into one i.e. BaseRetransmissionTimeout. Having just one counter on
> the RMS and RMD will reduce the run-time resources (much simpler
> state machine) required to implement RM-Assertions and avoid
> confusion (unknown states in state machine) caused by two timeouts.
> Having a separate timeout for sequence and retransmission may not
be
> necessary as activity on the RM link is transmission/retransmission.
> I believe one timeout i.e. BaseRetransmissionTimeout does not change
> the behavior of the system. Once this timeout occurs the sequence
> has to timeout as the implication of the timeout is the destination
> is either congested or offline.
>
> 2) If InActivityTimeout has to be there
as a parameter, we need to
> fully specify it with mechanisms for synchronization and keepalive.
> In addition, we need to discuss how the corner cases and other
> conflicts that occur when one has two timeout (as discussed in a-e
> above) are handled.
>
>
> Vikas
>
> Sonoa Systems, Inc.
> 3900 Freedom Circle, Suite #101
> Santa Clara, CA 95054
> (408) 748-1730 x100
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]