Stefan,
Thanks, this reply and the response's Doug's message
has been very helpful. I need to think about this more.
--umit
From: Stefan Batres
[mailto:]
Sent: Wednesday, Sep 14, 2005 1:00
PM
To: Yalcinalp, Umit;
Subject: RE: [ws-rx] New proposal for
i019 and i1028
Umit,
The purpose of the
cancel proposal it to define a mechanism to resolve doubt, which is an aid for
recovery, that is separate from the mechanism used for terminating. A benefit
of factoring these two independently is that we can enable doubt resolution
without terminating a sequence.
SeqFill (filling
gaps) is not for recovery:
-
Generically: Any
situation where an RMS knows that a message will never be acknowledged (be it
because it got a SeqCancelAck for it or because it decides never to send it in
the first place) will cause gaps in the acknowledgment ranges the RMD sends.
To compact those gaps the RMS uses SeqFill.
-
Specifically: Once a
message is cancelled, it is cancelled forever. The SeqFill is saying: The RMS
knows that the RMD has cancelled the message and thus the RMD no longer needs
to include the message in the SeqCancelAck. In this way the state the RMD is
maintaining for the SeqCancelAck can be compacted.
This proposal allows
the RMS to make the call of whether it wants to end a sequence with problems
or not.
Please let me know if
this helps to clarify your understanding of the
design.
Thanks!
--Stefan
From:
Yalcinalp, Umit [mailto:]
Sent: Wednesday, September 14, 2005 12:08
PM
To: Stefan Batres;
Subject: RE: [ws-rx] New proposal for
i019 and i1028
Stefan,
Thanks for the
explanation. I have some more questions.
I am trying to
evaluate the proposal with respect to the problem it is intending to solve.
Is it fair to say that the intent of the Cancel
proposal is to enable recovery without terminating (or
more precisely needing to abort from RMS perspective) a sequence when there
are problems? In this regard, can you clarify whether Filling the gaps is
intended to be used specifically for recovery? For example, after a
cancellation of a set of messages occur, the RMD notifies with the
cancellation ack. If the RMS decides to fill the gap for those messages that
have already been cancelled, it seems that RMS is allowed to resend
those cancelled messages to fill the gaps and hence the allows those
messages that were cancelled to be retransmitted. Did I get this
right?
If my previous
assumption is correct, it is not clear to me what happens when
CancelAck and SequenceFill are out of sync. Could you clarify?
Again, if my
assumptions/understanding is correct, is it fair to say that you are trying
not to close a sequence but patch the problem with additional exchanges?
It helps me
understand better if I understand the higher level motivation for the design.
Thanks again,
--umit
From: Stefan
Batres [mailto:]
Sent: Tuesday, Sep 13, 2005 6:56
PM
To: Yalcinalp, Umit;
Subject: RE: [ws-rx] New proposal for
i019 and i1028
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:]
Sent: Tuesday, September 13, 2005 6:01
PM
To: Stefan Batres;
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:]
Sent: Tuesday, Sep 13, 2005 12:50
PM
To:
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
