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" <>
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]
