Re: [ws-rx] New proposal for i019 and i1028

[Paul Fremantle <paul@wso2.com>]

Stefan

I agree with Umit that your proposal is more complicated. In the 
protocol as currently specified, it is fundamentally the RMD who is in 
control of the state of the sequence. The close proposal is a more 
specific way of ensuring that the state of the sequence is known at the 
RMS.

The cancel proposal adds a very specific change to the protocol in that 
the RMS now has a much more complex ability to modify the overall 
sequence state at the RMD, beyond the basic initiate, send messages and 
end that is supported today.

That isn't a criticism in itself. However, if there was a complaint 
about the close proposal changing the semantics of the protocol, this 
proposal changes them more significantly. I feel this proposal needs 
appropriately deep review.

Paul


Stefan Batres wrote:

> Umit,
>
> Thanks for taking the time to review this new proposal. First off I’ll 
> give the two proposals names in an effort to simplify the discussion. 
> I’ll call Doug’s proposal the “Close/FinalAck” proposal and I’ll call 
> this new proposal the “Cancel” proposal.
>
> Close/FinalAck and Cancel are not functionally equivalent. Cancel 
> allows for the same semantics as Close/FinalAck and provides a 
> separate and more general mechanism for resolving doubt.
>
> As you mention, the fundamental problem with the spec today is the 
> lack of a mechanism for resolving doubt. In the Close/FinalAck 
> proposal it is necessary to end a sequence in order to resolve doubt, 
> even if there is only a single message that can’t be transmitted. 
> While that is adequate to address i019 and i028 /as they are worded/, 
> it conflates the acts of ending a sequence and resolving doubt. The 
> Cancel proposal allows for doubt resolution independent of whether a 
> sequence is ended or not. Cancel can be composed with the existing 
> sequence termination mechanism to achieve the same result as 
> Close/FinalAck; ending a sequence with a final and accurate ack set.
>
> Also note that the Cancel proposal maintains the spec as is in that 
> there is one way to close a sequence and it remains unchanged.
>
> Thanks,
>
> --Stefan
>
> ------------------------------------------------------------------------
>
> *From:* Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
> *Sent:* Tuesday, September 13, 2005 6:01 PM
> *To:* Stefan Batres; ws-rx@lists.oasis-open.org
> *Subject:* RE: [ws-rx] New proposal for i019 and i1028
>
> Hi Stefan,
>
> Maybe I am looking at this in a simplistic way, but I can not follow 
> the issue you have with the current proposal and how the alternate 
> proposal addresses the issue.
>
> It seems to me the fundemantal problem is for the RMS to determine the 
> state of the RMD (thus resolving doubt) Thus, if the RMD were to send 
> the final acknowledgement along with the ack ranges that indicate the 
> messages that are received by the RMD, RMS has enough information to 
> reconcile its own status with the RMD (basically it can diff the 
> sequence numbers to obtain those messages which were in doubt but 
> confirmed to be received by the RMD per the final ack). I am not clear 
> as to why we need to do more here.
>
> Perhaps you can clarify for me why your proposal is a better proposal 
> and what the problem that Doug's proposal is not solving. It seems to 
> me that in both cases the protocol is changed, but the proposal you 
> are making is more complicated but functionally equivalent. I would 
> like to understand the motivation for the complexity.
>
> Thanks!,
>
> --umit
>
>     ------------------------------------------------------------------------
>
>     *From:* Stefan Batres [mailto:stefanba@microsoft.com]
>     *Sent:* Tuesday, Sep 13, 2005 12:50 PM
>     *To:* ws-rx@lists.oasis-open.org
>     *Subject:* [ws-rx] New proposal for i019 and i1028
>
>     All,
>
>     After much discussion Doug has managed to make me understand his
>     reasons for proposing his Close/FinalAck mechanism for addressing
>     i019 and i028. We now agree, an accurate acknowledgement state can
>     be helpful in order to resolve doubt and in addition, for cases
>     where a sequence must be ended, that acknowledgement state must be
>     final. These are preconditions for recovery and the protocol can
>     aid in establishing these preconditions.
>
>     However, we still have an issue with the current proposal [1]. We
>     think it conflates the notions of resolving doubt and closing
>     sequences. Attached is an alternate proposal that we believe
>     addresses this issue, allows for the exact semantics [1] provides
>     and has other advantages. Details are in the document.
>
>     [1]
>     http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00084.html
>
>     I look forward to the group’s comments.
>
>     Thanks,
>
>     --Stefan
>