Dan,
Comments inline . .
.
Current spec:
"<CloseSequence> indicates that the RM
Destination MUST NOT accept any new messages for the specified
Sequence"
Observe:
if RMS issues CloseSequence before receiving
all the acks, RMS is implying that is is not interested in completing current
sequence as is.
Not sure if I agree with this. The RMS may be making
some optimistic assumptions about the likelihood of messages
making it through. It may figure that 99.99% of the time the messages
always make it. It can inspect the final ack to detect the .01% case
and handle that as it sees
fit.
Implications:
- if RMS wants to
complete the sequence, it MUST NOT issue CloseSequence until RMS receives all
the acks.
Based on my above point, I'm not sure I agree with this.
In any case, PR022 has nothing to do with what the RMS does or doesn't want to
do. Its merely about providing the RMD with the information necessary to
detect when something has gone wrong with the Sequence.
- if RMS does not want to
complete the sequence, then (a) it is because AS doesn't care, in
which case there is no error and there is nothing to log on RMD side and AD
doesn't care either, or
(b) RMS intends recovery by analyzing FinalAck and placing un-acked
messages into a new sequence; once again any logging or other RMD action are
spurious, since "protocol" hasn't completed yet.
- if RMD does not care
(by configuration) about completing incoming sequence, there is no error to
log if sequence is incomplete - if RMD does care about completing incoming
sequence, RMD needs to force certain behavior out of RMS, namely, RMS waiting
to issue CloseSequence until RMS receives all the acks, perhaps, through the
use of an appropriate policy assertion. then, if RMS is compliant, receipt of
CloseSequence indicates to RMD that sequence is complete and
HighestAssignedSeqno field provides no additional value.
I'm confused about the idea of the RMS waiting to
issue CloseSequence until it receives acks for all the messages it
sent. The purpose of CloseSequence, as I understand it, is for the
RMS to obtain "true and final" information about which messages have been
received by the RMD and which have not. If the RMS already knows that the RMD
has received all the messages, why would it bother with a
CloseSequence?
I think we have gotten off the point. Let
me re-describe a use case. Suppose I am running some sort of
B2B hub. This hub has tens or hundreds of suppliers sending me business
messages such as "I commit to providing X number of part Y in timeframe
Z". It is very important to the suppliers to know if/when certain
messages did not go through. Consquently, their client software uses
CloseSequence in certain circumstances. On my end, I need to know when they
are experiencing troubles getting their messages to me. It could be that I may
need to extend certain deadlines to allow them to correct their problem etc So
lets say the following messages appear in a particular
sequence:
CreateSeq, Sequence Traffic Message (STM) 1, STM 2,
. . . STM 47, CloseSequence
Now, were there any problems with this sequence?
I CAN'T TELL !!!
All I am asking for is the ability of the RMD to
determine, at a very coarse level, whether a sequence completed
sucessfully or not. By "completed succesfully" I mean that the
RMD received every Sequence Traffic Message sent by the
RMS.
-
gp
Conclusion:
HighestAssignedSeqno is
useless.
Durand, Jacques R.
wrote:
Gil:
inline
-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Wednesday, November 15, 2006 2:51 PM
To: Durand, Jacques R.; Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
Jacques:
Point by point:
(1) It's not clear whether you support LastMsgNumber as a MUST in
TerminateSequence. The requirement for supporting this depends upon the
requirement for sending CloseSequence.
<JD> Given that we seem to agree on (2) below, I think we don't need to
make LastMsgNumber mandatory in TS - it should normally be always
communicated via CloseSequence.
(2) If it would allay your concerns, I would support the notion of
adding a
"Advize" value to IncompleteSequenceBehavior. The algorithm would be, if
IncomplateSequenceBehavior=[DiscardEntireSequence | Advise], then the
RMS
MUST send a CloseSequence message. What do people think about this?
<JD> I find this reasonable.
(3) While I think Bob's idea of requiring the CloseSequence message to
be
treated like a Sequence Traffic Message is interesting, it represents
too
great a change to make at this time. I'm also against the idea of
requiring
the RMS to retry either the CloseSequence or TerminateSequence messages
although we could note that an RMS MAY do so if it's willing to handle
the
possible fault(s) that may result.
<JD> Not saying anything in the specification about this is fine.
An RMS that needs a final Ack will normally send CloseSequence and
repeat it if needed to get this finalAck along with the ClSR. This
repeat is not required, but supported by those who care about this
feature. Same here: could be controlled by some out-of-scope policy
detail that only recommends a level of retries, for those who care.
Bob's idea, regardless of its merits, brings change to the model of
separation traffic/lifecycle message, and may have ripple effect
throughout the spec.
-Jacques
- gp
-----Original Message-----
From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: Tuesday, November 14, 2006 8:14 PM
To: Gilbert Pilz; Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
Gil:
I see three aspects in your proposal that need to be looked
at - or agreed on:
(1) Whether the LastMsgNumber is a MAY or a MUST in CloseSequence.
(2) Whether the CloseSequence message MUST be sent by the RMS
(or MAY, as of today). Similar issue with TerminateSequence.
(3) Whether any extra effort may be required to ensure the
reception of this LastMsgNumber marker, which is important
after all to your goal.
On (1), based on off-list conversations in our little task
force, I have no qualms anymore making it an unconditional
MUST. We see this creates no extra burden on an
implementation and that reduces the number of options. In the
same way as CloseSequence is the means to query a final ack
(for whatever use it serves), we could just decide it is also
the means to communicate a final sequence account. So fine.
On (2) I am not comfortable making this an unconditional MUST
as a general rule. After all, in many cases (where precisely
the RMD awareness you want to support is not required) the
RMS should not have to bother sending these lifecycle
messages. But I think you could achieve your goal at protocol
level (without conditioning this MUST to an external
agreement or DA), by relying on IncompleteSequenceBehavior
(ISB). Clearly if ISB is DiscardEntireSequence, it makes
sense that RMS be required to always close such sequence. We
could imagine another value for it like "JustAwareness" that
does not discard the sequence but requires awareness of
incompleteness, meaning also required closure.
On (3), I'd say some retry of CloseSequence would be expected
but should not be more specified than the retry of traffic
messages - left to external policy / agreement. Bob's
solution is tempting, but need to look at the implications of
making a lifecycle message also be a traffic message. Now I
think if you add a Sequence header to CloseSequence, you do
not need anymore LastMsgNumber...
Jacques
-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Tuesday, November 14, 2006 3:27 PM
To: Durand, Jacques R.; Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
Jacques:
You are right, there is a difference between (b) and (a). In
my mental model
(b) is inclusive of (a). That is to say, whenever the "all
messages received scenario" (described) below occurs, the RMD
knows that it has received all the messages that were sent.
I think we are in agreement about the expected behavior of
both the RMS and the RMD, we just need to agree on the
language to describe it.
- gp
-----Original Message-----
From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: Friday, November 10, 2006 7:48 PM
To: Gilbert Pilz; Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
Gil:
Actually, your initial goal as stated in your proposal:
(a)
" [In order] to allow the RM Destination to determine if it has
received all of the messages in a Sequence,..."
Is not quite the same as:
(b)
All we want is for the receiver
to have the ability to determine if this scenario
occurred or if it
didn't
The difference between these, is that in (b) you do not care at all
about receiving a TS/CS or not (in case not, the scenario
just did not
occur...), while in order to achieve
(a) you absolutely need a TS+LM or a CS+LM, otherwise you can NOT
determine if the messages you received form a complete
sequence. Now
we know that this last goal (a) is not always achievable
due to loss
of CS/TS. But we know it is desirable that the protocol
does its best
to ensure it. Which is why Stefan's question is legitimate.
Let's assume (a).
My take on this, is:
- an implementation should not be required to do this extra
effort of
resending CS or TS (concede it may not be clear in my
previous mail).
- in case an implementation decides to support this extra effort
(controlled by an external agreement, like details of
traffic message
resending), it is sufficient to do resending of CS, not of TS.
- In all cases, and RMD implementation never needs to keep sequence
state after it got the TS.
Not sure where the "overkill" is :-)
Jacques
-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Friday, November 10, 2006 3:36 PM
To: Durand, Jacques R.; Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
This is a giant overkill. Consider the following scenario:
1.) RMS and RMD exchange CS/CSR
2.) RMS sends a number of messages. Very few, if any, are lost.
3.) RMD acks the messages.
4.) RMS re-sends any messages that aren't acked; RMD
eventually gets
them and acks them.
5.) RMS and RMD exchange TS/TSR.
I would argue that this scenario will apply to an overwhelming
majority of the WS-RM Sequences that are ever created. All
we want is
for the receiver to have the ability to determine if this scenario
occurred or if it didn't.
It's a very simple idea. If some of the messages never get through
(including CS or TS) that falls into the "something went wrong with
the Sequence" bucket.
- gp
-----Original Message-----
From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: Thursday, November 09, 2006 3:29 PM
To: Stefan Batres; Gilbert Pilz; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
Stefan:
In the light of today's discussion, and looking at this from an
"agreement" perspective, where the requirement for an RMD
to notify
its party if it missed any message in a sequence is
conditioned by an
[out-of-scope] agreement that would be known from both parties:
- if there is such an agreement, then I would assume the RMS must
ensure the RMD got its LM (and if it failed to do so,
should notify,
etc.) But this agreement could mean for RMS to do LM in
CloseSequence
and retry as much as needed, until getting the CSR, instead of
focusing on TS. That seems more appropriate because the
time between a
CloseSeq and a TS is precisely intended for both parties
to get in
sync.
- It does not have to mandate more from TS/TSR, which
would be more
demanding on implementations: if RMD sent its TSR, it
should be free
to reclaim resources immediately, regardless if RMS got
it. RMS may
try to resend TS with no success but there is no harm:
TS/TSR are just
resource optimization features as before, once LM has been
secured by
CloseSequence exchanges.
-Jacques
-----Original Message-----
From: Stefan Batres [mailto:stefanba@microsoft.com]
Sent: Thursday, November 09, 2006 1:00 PM
To: Gilbert Pilz; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] PR Issue 22: concrete proposal
Gil,
This seems sane too me. I do have an issue that is not directly
related to PR0022 but seems somewhat related to how we address it.
With the spec as-is and with your proposed changes we
don't have a
quick resource reclamation mechanism like we did in the submitted
spec. For example:
I am an RMS.
I send one of these TS with LM.
Should I retry if I don't get a response? Probably yes.
You are an RMD.
You get my TS with LM.
You send a TSR.
Since the TSR might get lost, and because I might retry
the TS, you
should be ready to respond to my TS retry.
How long do you remember the sequence in case I retry?
In the submitted spec, if you got the TS you could
immediately forget
about the sequence and never respond again. This worked
because we put
the LM in a Sequence header.
Thanks
--Stefan
-----Original Message-----
From: Gilbert Pilz [mailto:gpilz@bea.com]
Sent: Thursday, October 26, 2006 12:49 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] PR Issue 22: concrete proposal
Attached is a proposal for PR i022 in the form of a diff against
CD-04.
The main points are:
1.) wsrm:TerminateSequence has been expanded to include a
mandatory
LastMsgNumber element the value of which is, surprisingly
enough, the
number of the last message in the Sequence.
2.) Sending wsrm:TerminateSequence is now mandatory;
basically the
whole thing won't hold together unless the RMS is required
to send a
wsrm:TerminateSequence.
<<wsrm-1.1-spec-pr-i022.pdf>>
|