RE: [ws-rx] Issue i005

[Christopher B Ferris <chrisfer@us.ibm.com>]

As I mentioned on the call, I think that what needs to be said in the spec 
could be most constraining on the
RMD perspective. 

Proposal: 

An RMD MUST NOT issue a <SequenceAcknowledgement> containing a <Nack> for 
a message(s) that
it has previously acknowledged within an <AcknowledgementRange>.

An RMS SHOULD ignore a <SequenceAcknowledgement> containing a <Nack> for a 
message(s) that
has previously been acknowledged within an <AcknowledgementRange>.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

"Winkler, Steve" <steve.winkler@sap.com> wrote on 08/25/2005 04:19:31 PM:

> Hi Doug,
> 
> As I mentioned, the actual wording can be left to the editors as long as 
the semantics have been 
> agreed upon.  The proposal was sent simply as a starting point for 
discussion.  My interpretation 
> of the spec as it stands is that a nack can be ignored.  The proposal 
was to add words to state 
> that messages should be retransmitted in response to a Nack, but given 
that nacks are intended 
> only for performance optimization, I don't think that this behavior 
should be required.  I do 
> think, however, that we should encourage 'better' implementations that 
follow recommended 
> optimization practices unless a specific implementation instance has 
sufficient reason not to. 
> 
> Cheers,
> Steve
> 
> 
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Thursday, Aug 25, 2005 12:59 PM
> To: Winkler, Steve
> Cc: Marc Goodner; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Issue i005

> 
> The wording seems a bit backwards to me.  I think that retransmission 
upon receipt 
> of a NACK is required except when the message as been previously ACKd. 
The text 
> as stated implies that a NACK can be ignored even when its has not been 
ACKd. 
> (Why do I feel like Bill The Cat :-) 
> 
> I'd prefer something more like: 
> 
> An RM Source MAY choose to not retransmit the message corresponding to 
> <Nack> element in cases where it previously received an acknowledgement 
for 
> that message. 
> 
> Although, I also see no reason to not go one more step and say that the 
RMS 
> should always ignore the NACK in those cases too.  But this isn't a bad 
compromise. 
> 
> thanks, 
> -Doug 
> 
> 

> 
> "Winkler, Steve" <steve.winkler@sap.com> 
> 08/25/2005 02:16 PM 
> 
> To
> 
> "Marc Goodner" <mgoodner@microsoft.com>, <ws-rx@lists.oasis-open.org> 
> 
> cc
> 
> Subject
> 
> RE: [ws-rx] Issue i005
> 
> 
> 
> 
> 
> Hi Marc,
> 
> The more compact wording is fine with me with the exception that you've
> changed the SHOULD to a MAY.  I personally like the stronger wording,
> but understand that it is an optional performance enhancement.  I think
> the semantic difference between SHOULD and MAY should be decided by the
> TC. 
> 
> I also think that we may need to investigate the ability to advertise
> the ability for destinations to trigger retransmissions with Nacks as a
> policy.  I'll look into this a little more and possibly raise a separate
> issue to address this.
> 
> Cheers,
> Steve
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> > Sent: Thursday, Aug 25, 2005 9:58 AM
> > To: Winkler, Steve; ws-rx@lists.oasis-open.org
> > Subject: RE: [ws-rx] Issue i005
> > 
> > Steve, 
> > 
> > I propose the following more succinct wording to be used at 
> > Section 3.2,
> > after line 338 in place of what you have proposed below.
> > 
> > "The RM Source MAY retransmit the message corresponding to the <Nack>
> > element when it has not already received an acknowledgement for that
> > message."
> > 
> > -----Original Message-----
> > From: Winkler, Steve [mailto:steve.winkler@sap.com] 
> > Sent: Thursday, August 18, 2005 2:11 PM
> > To: ws-rx@lists.oasis-open.org
> > Subject: [ws-rx] Issue i005
> > 
> > 
> > 
> > Issue i005 was originally brought up at the F2F, not 
> > necessarily by me,
> > but I was an active part of the discussion and therefore would like to
> > continue that discussion on the list.  I've included some background
> > information to expound upon the description and I've followed with a
> > concrete proposal that I hope the TC will consider as a starting point
> > for resolving the issue. 
> > 
> > Cheers,
> > Steve
> > 
> > 
> > Background
> > 
> > The asynchronous nature of acks, as well as line 336/337 of the spec
> > indicate that 'The RM Destination MAY send a <SequenceAcknowledgement>
> > header block at any point.'  In certain cases, this could result in an
> > Ack for a given message overtaking an Nack for the same message.  The
> > rationale given for the Nack is that the gap analysis can be performed
> > on the RMD side resulting in performance enhancements (see lines
> > 376-378).  In the case that the Nack overtakes an Ack, the Nack could
> > actually go against the spirit of the spec and result in performance
> > degradation by triggering the retransmission of a message that has
> > already been received by the RMD.  It should be noted that receipt of
> > this message by the RMD a second time is in no way an error, 
> > but simply
> > an unnecessary inefficiency in the protocol for this edge 
> > case.  Better
> > implementations would have probably avoided this anyway.
> > 
> > Several people during the discussion at the F2F mentioned 
> > that there may
> > be some benefit in Nacking a message to trigger resending of a message
> > that has already been received by the RMD.  Whereas I can see 
> > that this
> > may be true, it seems like this kind of functionality would need to
> > happen at a layer above RM (i.e. it's out of scope for this spec).
> > However, given that messages can be delivered multiple times 
> > anyway, it
> > would not be the end of the world to retransmit a message that has
> > already been delivered to the RMD.  Therefore I would not want to
> > preclude an implementation that wants to '(ab)use' this fact 
> > from being
> > allowed to use the RM machinery already in place to achieve this. 
> > 
> > I also noticed while investigating this issue that there 
> > doesn't seem to
> > be any explicit indication in the spec that a Nack message should
> > trigger the resend of a message.  I believe that this is implied, but
> > since it's an optimization, it is also most likely not 
> > intended to be a
> > requirement. 
> > 
> > Proposal: Add text to the spec to explicitly state what an 
> > RMS should do
> > when it receives a Nack message and tighten the spec for the edge case
> > described above in the following manner (wordsmithing can be 
> > done later,
> > but you get the gist):
> > 
> > In Section 3.2, after line 338 add something like this: 'If the RM
> > Source should receive a <SequenceAcknowledgement>containing a 
> > Nack, the
> > RM Source SHOULD retransmit the message corresponding to the 
> > Nack. After
> > the notification of successful receipt of a given message by the RM
> > Destination, the RM Source SHOULD NOT attempt to retransmit 
> > the message
> > in the event that it receives a negative acknowledgement for it at a
> > later point in time.'
> > 
> > 
> > ------------------
> > Steve Winkler
> > SAP AG
> >