RE: [ws-rx] Issue i005

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

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
>