RE: [ws-rx] PR Issue 22: concrete proposal

["Gilbert Pilz" <Gilbert.Pilz@bea.com>]

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.

(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?

(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.

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

smime.p7s