Stefan:
sorry for jumping late into this, had not
had time to review the Cancel proposal until recently.
A very quick feedback:
-
there
are interesting things in this proposal, seems to address a broader issue
though. (shouldn't we first submit this issue and accept it?)
-
I wouldn't
be as affirmative as others on this thread that the proposal can't do
what CloseSequence is doing. In terms of controlling the RMD, it seems that an
open-ended SequenceCancel (or with a single range element from 1 to maximum ...)
can just do the same job. The ack process seems heavier, because it is
precisely targeted to a broader issue. But again unless we acknowledge there is
a broader issue to resolve than just i019 and i028, I do not see much advantage
compared with the current proposal from Doug.
-
I have
some sympathy for the attempt at reducing the ack overhead (due to gaps) on the
long range, but that seems to me yet another issue (dissociated from what
Cancel tries to do), namely reduce the overhead of Ack size (isn't that same
issue Chris filed?) IMO, there might be a way to reduce Ack size while avoiding
resorting to something like SequenceFill.
-
I'd
like to see an issue or more filed and accepted here, before judging the merits
of Cancel and "Ack sprucing".
Regards,
Jacques
From: Stefan Batres [mailto:stefanba@microsoft.com]
Sent: Wednesday, September 14,
2005 2:03 PM
To: Doug Davis;
ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] New proposal
for i019 and i1028
Doug,
Thank you for your careful review of this
proposal. I have some comments regarding some of the points you make and
I'm also including answers to some of the detailed questions you've
made.
I will propose a new issue relating to
gaps.
Cancel relates to i019 and i028 to the
same degree as Close does because it addresses them in the same way; by
providing a mechanism that an RMS can use to end a sequence with a final and
accurate ack set. Attached is an example of how to do this using Cancel.
Cancel addresses a superset of the issues
addressed by Close; i019, i028 and the yet-to-be-named issue related to gaps.
I don't expect Cancel to change the
protocol at all but rather to just add to the protocol. In fact, it could
plausibly be its own document (I not advocating for or against that, I'm just
making a point).
I acknowledge that the amount of sequence
state Cancel adds is a concern. I think the benefits of factoring the
mechanisms used to end sequences and resolve doubt independently outweigh these
concerns. This clean factoring could potentially allow for different levels of
support allowing for someone to support only sequence termination with a final
accurate ack set and not incur any extra state management. I have to say I need
to give this "different levels of support" idea some further
thought since I just thought of this as I read your comments.
If a new issue is opened and accepted,
then, since Cancel addresses i019, i028 and i0<whatever>, I don't
see why we'd need Close as well.
Answers to some of the other detailed
questions:
Q: How does an RMD "never accept
messages"?
A: It ignores them.
Q: Is the SeqCancelAck header on all
messages that have a SeqAck header?
A: No.
Q: What if the SeqCancelAck is lost? Do we
need a CancelAckRequested?
A: RMS can resend SeqCancel.
Q: How does an RMS know whether a
particular message was filled-in or cancelled?
A: The RMS is driving; if it wants to know
if a particular message was captured or not then it should include that message
in a SeqCancel before including it in a SeqFill.
Q: What is the distinction between
canceling and gap-filling?
A: Canceling, by itself, resolves doubt
about the transmission of messages. Gap-filling, by itself, fills gaps in the ack
set, possibly incurring doubt. Canceling followed by gap-filling resolves doubt
and compacts the sequence state.
Q: Does filling a gap remove those
messages from future SeqCancelAck headers?
A: Yes.
Thanks again.
--Stefan
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, September 14,
2005 6:56 AM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] New proposal
for i019 and i1028
Stefan,
I'm
glad that you guys finally see the need for the proposal. I
must admit
though, I don't see how this proposal actually relates to
the
specified issues. Both issues relate to how an RMS can get a final
and accurate
accounting of the sequence from the RMD - in one case
because of a
fault and in another because the RMS decides to stop
using the
sequence. This proposal, if viewed as a complete replacement
for mine
does not address these at all.
Your
proposal focuses more on gap-filling (2 variants of it) and
neither of
these is mentioned in the issues. And as such I think a new
issue should
be opened and this can be offered up as a potential
solution for
it. Once that is done, I then have some comments and
questions
about it:
- How
does an RMD "never accept messages" that have been cancelled?
Does it throw a fault? Ignore them?
- Does
a SeqCancelAck header get carried on all messages that have a
SeqAck header? In order for the RMS to get an accurate view of the
sequence it would need all of this info each time.
- If
'no', then are you proposing an CancelAckRequested header as
well since the SeqCancelAck headers could be lost and there needs to
be some way for the RMS to ask for it.
- The
SeqCancel and SeqFill headers are not information - like the
AckReq and SeqAck headers. As Dan noted in [1] dealing with these
headers when piggy-backed on other messages could be problematic.
Dan's proposal is that any fault generated by these headers should not
influence the processing of the original message - and that implies
that in some cases the fault may be simply dropped. Which is no
big deal since these headers are mainly informational anyway. The
new headers you've introduced are not simply information though - they
are critical to the success resolving doubt. In the past I said
that
the Close() in my proposal could be a header - its just a syntax
difference. You're proposal makes me realize that it really can't
be.
The Close(), much like your SeqCancel and SeqFill headers, are much
more serious than the informationally piggy-backed headers we have
now. And as such they deserve to be treated with more seriousness.
-
After the RMD receives a SeqFill header how does the RMS know whether
any particular message was 'filled-in' or the message was just late
in arriving at the RMD? Does this mean that to fill a gap, the RMS
should send a SeqCancel, then wait for a SeqCancelAck, then send
a SeqFill? Unless the RMS never sent the message, or doesn't care
that it go there, I don't see what else it could do.
- The
distinction between Cancelling and Gap-Filling a hole in a sequence
seems almost arbitrary and redundant. There is no clear way for an
RMS to know which one to use when.
- As I
read it, the distinction between SeqFill and SeqCancel isn't clear
and almost arbitraty.
-
Actually, perhaps you believe that gap-filling is for cases where the
RMS never actually sent the message. And while I don't dispute this
might be a valid use-case my initial reaction is that this should not
be something the spec deals with. We've specifically avoided having
the spec talk about things outside of what goes on the wire - things
like how the DA might influence the protocol - so following that same
logic it doesn't seem right to take into account some processing
that takes place before the RM logic. If inOrder processing across
sequences is out of scope then this feels like it should be too.
But
I need to think more about it.
-
You've introduced quite a lot more data for the RMD and RMS to manage.
The RMD must now maintain an ACK list and a CancelList - and both
must be kept to inform the RMS of the sequence state.
The RMS must now maintain an ACK list, a CancelList and a Gap-List -
and all three must be kept in order for the RMS to have an accurate
accounting of what happened to each message.
And merging/reconciling these lists could be quite
expensive (remember, we introduced Nacks just because one list could
be hard for some impls - imagine what 3 overlapping ones will do).
- You
claim that the Close proposal introduces another way of terminating
a sequence - this is false. Please explain this by showing me where
in
the proposal it does this. Terminate does not change at all.
The
proposal simply allows for the RMS to tell the RMD to not accept any
more messages for the sequence - that is very different than Terminate
which involved resource reclaimation.
- There
is still no mention of how to know for sure which Ack received by
the RMS is the final one - which is the point of the Close proposal.
-
Given the only reason for gap-filling in this proposal is to shrink the
SeqAck header, does filling a gap remove it from the SeqCancelAck? If
not, this could also continue to grow.
- This
change means that it is impossible to examine a SeqAck header and
see which messages were delivered, due to gap-filling. Whilst this
doesn't break the protocol, it also doesn't help in terms of debugging
problems. It doesn't feel right for the SeqAck header to lie about
which messages were really received, just so it has less entries in it.
Overall, I
think this proposal is addressing a very different set
of issues
from the original one proposed - and does so in a way that
significantly
changes the protocol. I would suggest that you rework it,
as Paul
Cotton suggested during one of our previous phone calls, into a
form that
would allow the TC to see the specific spec changes you want.
I think that
will draw out even more questions than what I've listed above.
And, once
that happens I think it will be even more obvious that this is
a separate issue
from the other proposal so please open a new issue with
the
use-cases this proposal addresses so the TC can get a more complete
view of what
is driving this. And in the end I suspect you'll find that
both could
be needed and we should proceed with the other proposal as is.
thanks,
-Doug
[1]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00048.html
"Stefan
Batres" <stefanba@microsoft.com> wrote on 09/13/2005 03:49:46 PM:
> 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
>
[attachment "WSRM-Cancel.doc" deleted by Doug
Davis/Raleigh/IBM]