Re: [ws-rx] Issue i005

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Winkler, Steve wrote:
> 
> 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.  

What is the advantage in doing that from a reliable messaging protocol 
POV? The message has already been received and the sender knows this.

> 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