Re: [ws-rx] NEW ISSUE: semantics of "at most once" delivery assurance

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

Doug is exactly right. I thought I had made this point clear in my 
overview presentation at the F2F.

The WS-RM protocol itself is an AtLeastOnce protocol as observed between 
the RMS and RMD.
That means that the RMD must sucessfully receive each message in the 
sequence at least once.
That means that the RMS is responsible to retransmit any message that is 
unacknowledged (within
the relevant intervals, etc.)

The DA does not effect what goes on the wire. It is a contract between the 
RMD and AD logical
components. For AtMostOnce, the RMD is permitted to "drop" messages (e.g. 
in the case where the
RMS has a limited store for unprocessed messages and it wants to effect a 
LIFO or FIFO algorithm
to drop one or more of the received (and acknowledged) messages on the 
floor.

I have heard arguments that AtLeastOnce as a DA between RMD and AD makes 
no sense as there
is already a need for the RMD to check for duplicates, etc. Whatever...

I think that for the most part, the DA that will have the most use will be 
ExactlyOnce, but there are
valid use cases where one could certainly envisage AtMostOnce being quite 
relevant.

To Anish's point, The use and purpose of Nacks is to optimize the protocol 
by taking an optimistic view of the
inherent reliability of the network. e.g. the frequency of acks could be 
tuned way down and nacks
used to compensate for when the RMD knows it wants a particular message to 
be retransmitted.

For the protocol to complete "correctly", a SequenceAcknowledgement with 
AcknowledgementRange
elements covering the complete range of MessageNumbers for the Sequence 
MUST be received by the 
RMS.

A Nack is not an Ack. Just because the RMS receives a Nack does not mean 
by any stretch of the imagination
that the resultant retransmission of the message will be successfully 
received by the RMD. Of course the
RMS is required to respond to successive Nacks of the same message.

In the case when the RMS does not have the message to be retransmitted, 
then the Sequence must be terminated
by the sender.

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

Doug Davis/Raleigh/IBM@IBMUS wrote on 07/25/2005 03:09:17 PM:

> 
> Hi, 
> No matter what the DA is, any unACK'd message needs to be resent. 
> DAs have no impact on the protocol itself. 
> thanks, 
> -Doug 
> 
> 

> 
> Anish Karmarkar <Anish.Karmarkar@oracle.com> 
> 07/25/2005 01:11 PM 
> 
> To
> 
> tom@coastin.com 
> 
> cc
> 
> wsrx <ws-rx@lists.oasis-open.org> 
> 
> Subject
> 
> Re: [ws-rx] NEW ISSUE: semantics of "at most once" delivery assurance
> 
> 
> 
> 
> Two related questions that need to be answered are:
> can a RM receiver send a NACK in case of AtMostOnce DA? If yes, what is 
> the RM sender supposed to do when it receives such a NACK and it is 
> never going to retransmit the message (as it has already thrown away the 

> message) -- i.e. to prevent the RM receiver from NACKing the message 
> repeatedly, should the RM sender send a specific fault?
> 
> -Anish
> --
> 
> Tom Rutt wrote:
> > *Title*: Semantics of  "At most once" Delivery assurance.
> > 
> > *Description*:
> > The semantics of the "at most once" delivery assurance are not clear.
> > 
> > One interpretation is that at most once implies that the sender is not 

> > required to retransmit mesages which are not acked.
> > 
> > *Justification*:
> > It is important to clarify whether the sender must retransmit 
> > unacknowledged messages when the "at most once" delivery assurance is 
in 
> > use.
> > 
> > *Target*: (core | soap | wsdl | policy | schema | all)
> > all
> > 
> > *Type: *(design | editorial)
> > design
> > 
> > *Proposal*:
> > 
> > Clarify the semantics.  There are at least three possible semantics 
> > associated with "at most once"
> > 
> > proposal 1) at most once means that the sender will never retransmit a 

> > message, regardless of whether it is acknolweged by the destination.
> > 
> > Proposal 2) The sender may retransmis messages, but is not required to 

> > to so,  however the destination will not deliver duplicates
> > 
> > Proposal 3) the sender must retransmit messages, however the 
destination 
> > may drop messages in times of resource saturation, but will never 
> > deliver a duplicate.
> > 
> > *Related issues*:
> > Issue 9
> >