Chris, your interpretation is correct.
As several people have pointed out, duplicate elimination
on top of AtMostOnce may be desirable, but that is a private
matter between the RMD and the AD.
All the best, Ashok
> -----Original Message-----
> From: Christopher B Ferris [mailto:]
> Sent: Monday, July 25, 2005 6:11 PM
> To: wsrx
> Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once"
> delivery assur ance
>
> Jacques,
>
> That's not how I interpreted Ashok's note. I think he was
> suggesting that it would be a waste to bother with ws-rm if
> you wanted AtMostOnce between RMS and RMD.
>
> Basically, I think he was saying: don't use rm for that.
>
> Of course, I could be completely wrong in that understanding.
> However, if that's what he meant, then I concur.
>
> Cheers,
>
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email:
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
>
> Jacques Durand <> wrote on 07/25/2005
> 08:35:14 PM:
>
> > But Ashok seems to also make the point that when AtMostOnce alone is
> requested, then there is no
> > reason for the protocol (and for RMS / RMD) to incur the overhead of
> Acks and resending mechanism...
> > -JD
> > -----Original Message-----
> > From: Christopher B Ferris [mailto:]
> > Sent: Monday, July 25, 2005 1:58 PM
> > To:
> > Cc: Anish Karmarkar; Doug Davis; Tom Rutt2; wsrx
> > Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once" delivery
> assurance
> > Ashok,
> > I gather that you don't think that the protocol itself
> should be used
> > to
>
> > provide an AtMostOnce
> > assurance between the RMS and RMD, and that the contract
> between the
> > RMD
>
> > and AD is
> > whatever the two have established between themselves (they can do
> whatever
> > they like).
> > I think that I pretty much agree on this point.
> > Cheers,
> > Christopher Ferris
> > STSM, Emerging e-business Industry Architecture
> > email:
> > blog: http://webpages.charter.net/chrisfer/blog.html
> > phone: +1 508 377 9295
> > Ashok Malhotra <> wrote on 07/25/2005
> > 04:30:27
> > PM:
> > > > The WS-RM protocol itself is an AtLeastOnce protocol as
> observed
> > > > between the RMS and RMD.
> > >
> > > Let's make a note of this! If this is the case, then how is
> AtMostOnce
> > > an option as some messages may not be delivered. Sure
> RMD can throw
> > messages
> > > away but then it can do whatever it wants with the messages.
> > >
> > > To my mind, AtMostOnce is not 'reliable' messaging.
> > >
> > > And if you want AtMostOnce why build the apparatus of a
> RMS and RMD
> > > and starting sequences etc. Why not just send messages
> and be done
> with
> > it.
> > > They may or may not get there, but that's the protocol.
> > >
> > > All the best, Ashok
> > >
> > >
> > > > -----Original Message-----
> > > > From: Christopher B Ferris [mailto:]
> > > > Sent: Monday, July 25, 2005 1:08 PM
> > > > To: Doug Davis
> > > > Cc: Anish Karmarkar; ; wsrx
> > > > Subject: Re: [ws-rx] NEW ISSUE: semantics of "at most once"
> > > > delivery assurance
> > > >
> > > > 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:
> > > > 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 <>
> > > > > 07/25/2005 01:11 PM
> > > > >
> > > > > To
> > > > >
> > > > >
> > > > >
> > > > > cc
> > > > >
> > > > > wsrx <>
> > > > >
> > > > > 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
> > > > > >
> > > >
> > > >
> > > >
> > >
> > >
>
>
