OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]