RE: [ws-rx] Issue i005

["Winkler, Steve" <steve.winkler@sap.com>]

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
>