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
