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

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



+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]