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

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

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