[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Proposal for closure of Issue i022, RM Assertions
+1 to the proposed modifications here. I
would be supportive of a new issue being filed as described below. From: Bob Freund
[mailto:bob.freund@hitachisoftware.com] Argument: 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) 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
back off may be implemented many ways, there is more than one algorithm that
use different parameters 5) Back off
algorithm selection may be implementation specific, what is good for cell
phones may not be good for cluster interconnected nodes or crossbar connected
multiprocessors 6) I have found
no theoretical modeling published concerning stability of specific back off
algorithms which consider the case of web services cum intermediaries 7) Most
published data concerning the behavior of back off algorithms examine fairly
simple network segment related saturation and do not address client, server,
let alone intermediary saturation. 8) Exponential
back off algorithms need an adaptive 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 back off mechanism is
required; however implementation specific needs are not served well by the
specification of any specific algorithm for all potential implementations of
WS-RM. It is recommended that implementers utilizing IP based
transmission media consider the mechanism described in RFC 1323. In
additions, acceptance of this proposal removes all mention of re-transmission
which is a required for correct operation of the protocol. These however are
beyond the scope of the issue as stated. Therefore: Delete all re-transmission
parameters as described in the WS-RM Policy specification [1] since they are
unnecessary and unhelpful should the implementer use an algorithm with a
different set of controls. Note: A new issue should be opened to address
the location and manner by which re-transmission behavior is specified. Thanks -bob Specific modification to documents: In [1] Delete lines indicated with cross-out in the attached
document, Adjust portions highlighted in attached document to reflect
line number modifications resulting from deletions References: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]