[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Issue 129: Define "discard"
|
OK, If WS-RX is defining a protocol
specification and what is in-scope is defined by the diagram located in section
2 figure 1, then all discussion of the AD to RMD interface is out of scope.
Rationale for continuing in this direction is that (and has been argued before)
behavior beyond the wire protocol is not testable and not observable on the
wire. Section 2 of this specification states that it enables a number of
potential reliability features including (ref wd14 lines starting at 114) ordered
delivery, duplicate elimination and guaranteed receipt. It goes on to say
that regardless of which reliability features are implemented. The wire
protocol does not change. The motivation for issue 106 was that starting
in section 2 line 117 the specification states that the RM Source can, except
in the most extreme circumstances, accurately determine the disposition of each
message transmitted as perceived by the RM destination, so as to resolve any
in-doubt status regarding receipt of the messages transmitted. It was argued by several, IBM included,
that the protocol was all about transfer, and not about delivery, but the
delivery word was used in many places. This, the word was replaced with
transfer in many places throughout the document. Perhaps we missed a few.
The problem was that if the spec is not
about delivery, and if the RMD/AD interface is out of scope (which is right and
proper for a wire protocol specification), then it was not possible to
implement ordered delivery behavior containing no gaps without the
communication from RMD to RMS of what the RMD/AD combination might do in the
case of sequence closure or termination of a sequence that contains one or more
unacknowledged messages with a sequence number lower than one or more
acknowledged messages in such a way so that the RMS had no doubt as to the
status of those acknowledged messages that followed the first unacknowledged
message. If merely duplicate elimination were in force at the destination
side, then the RMS presumably could assume that all messages acknowledged might
eventually be delivered (acknowledgement indicates that the RMD has taken
responsibility). On the other hand, if ordered delivery, which might have
been better described as ordered processing, were in force, then some potential
implementations may never process acknowledged messages that follow one or more
unacknowledged messages. Thus there was always doubt at the RMS as to the
ending status. The IncompleteSequenceBehavior element was
introduced so that the RMS may discriminate between those messages that had
been acknowledged and that stand a chance of being processed, noting that there
are no guarantees since it is not even known if the AD exists or is operating
correctly, and those messages that had been acknowledged and that stand no
chance whatsoever of being processed. This was an attempt to narrow the
window of doubt concerning ending sequence status. What the IncompleteSequenceBehavior
element was intended to convey was effectively a way that the RMS might understand
what messages at the end of an incomplete sequence were lost even although
acknowledged and nothing more. There is no indication what the RMS is to
do with this information, other than have the correct ending status which
presumably might be retrieved by the AS in some way out of scope of this
document. This was intentional. The word dropped was used to
indicate to the RMS the effective behavior of the RMD/AD without needing to
specify exactly how this might be implemented or how the reliability features
were divided in implementation between the AD and RMD. The spec is simply
silent on these issues since there is no impact on the wire protocol. I can imaging implementations where the
RMD has the ability to communicate “forget about those message X that
delivered” to its associated AD. I can also see the need for implementations
that might only care that all messages be processed in order but a missing
message now and again might be no big deal. The RMD and AD are free to do
whatever is enabled by the protocol. I feel that constraining implementations
to do things such as to persist messages across system failure events or to only
deliver a complete sequence or none at all is beyond the intent of the protocol
specification, on the other hand, I will fight to allow the protocol to support
implementation of a wide variety of reliability features in any way their
designers see fit. Maybe the AD has roll-back capability? I think we must
allow for the possibility without prohibiting it, since after all it is all
about transfer, and not delivery. At least the wire protocol now contains
sufficient information for the specification to live up to its section 2
promises. I suggest that we close this issue with no
action as my first choice. Any second choice supportable by me cannot
constrain the RMD/AD implementation of this protocol in ways that do not affect
the protocol. One way is to define a discarded message, if its dictionary
definition is inadequate, to mean a message that sure as heck will not be
processed by the AD. Thanks -bob From: Durand, Jacques
R. [mailto:JDurand@us.fujitsu.com] Editorial comment: as defined, “discard” *exactly* means “not deliver” as
far as the observable behavior of RM is concerned…. So this proposal
should honestly use the term deliver already in the glossary instead of adding
a redundant term actually defined as “discard: to not deliver”. More substantial comment: I can’t find in the archives the
original motivation behind wsrm:IncompleteSequenceBehavior
, but for me it always had a non-normative value – a
hint for the RMS about the RMD behavior that the RMS can use for optimization
purpose. This proposal below by effectively
conveying a delivery assurance commitment from RMD to RMS, goes far beyond, and
the fact that the feature is optional does not change its nature. If we go that
route, why not more generally convey in CSR the DA conditions this sequence
will be submitted to on RMD side? (dup elimination or not, different flavors of
ordering, …) I am not necessarily objecting to this, but IMO i129 is not
the place to resolve this. If the RMS wants to have some contractual
assurance on the RMD delivery behavior, it can be obtained (a) either
out-of-band like any other DA, (b) or in case this is too dynamic (subject to
change with each sequence, based on resources, etc.) then the use of IncompleteSequenceBehavior
can be more formally bound to an out-of-scope agreement /
policy. Still, my RMD may want to send a hint on
its general behavior so that the RMS can behave more efficiently, but it may
not want to formally – or strictly - commit to this (unless again
out-of-band agreement).
So I would keep it simple on the
replacement of “discard” (either use “not deliver” or
“not process further”) and remove the RFC2119 keywords…
getting back to something close to the initial DougD proposal I believe… Jacques --------- Doug Davis wrote: --------- /wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]