oops, disregard the previous forward... THIS is the email Rebecca asked me
to forward:-)
Cheers,
Christopher Ferris
STSM, Emerging e-business Industry Architecture
email:
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295
----- Forwarded by Christopher B Ferris/Waltham/IBM on 07/26/2005 11:59 AM
-----
"Bergersen, Rebecca" <> wrote on 07/26/2005
11:06:09 AM:
> Chris,
>
> I disagree. 'At Most' does not have the same semantics as 'Exactly'.
> 'Once' does imply duplicate detection, as you said, but 'At Most' does
> not imply best effort. It simply means 'maybe fewer but no more than'.
> If you think Best Effort should be the semantic, then AtMostOnce should
> be dropped. A threshold on 'ExactlyOnce' such as you suggest can be set
> by default at a Very Large Number thereby specifying the absolute best
> effort with smaller values providing 'good enough effort' at delivering
> a message exactly once.
>
> That would give you what you want, but for different reasons I'm not
> convinced that AtMostOnce has any place at all in a "Reliable Message'
> protocol. AtMostOnce (maybe zero but no more than one) implies the
> message can be lost or dropped without significant consequence. As a
> result, the sender can send it and forget it and the receiver can deal
> with it if it gets it (and avoid more than one copy being given to the
> application) but not worry about it if it doesn't get it. If less than
> one is acceptable, there is no requirement for reliability here. This
> type of message can be sent outside the 'Reliable Message' protocol.
>
> Regards,
> Rebecca Bergersen
> Principal Architect, Middleware Standards
>
> -------------------------------------------------------
> IONA Technologies
> 200 West Street Waltham, MA 02451 USA
> Tel: (781) 902-8265
> Fax: (781) 902-8001
> -------------------------------------------------------
> Making Software Work Together TM
>
> -----Original Message-----
> From: Christopher B Ferris [mailto:]
> Sent: Tuesday, July 26, 2005 6:43 AM
> To: wsrx
> Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once" delivery
> assur ance
>
> Umit,
>
> I actually *do* see use cases for AtMostOnce DA observed between the RMD
>
> and AD. It relates to
> best effort with duplicate detection, really. Again, consider an
> endpoint
> with constrained resources.
> It will provide reliable delivery with ExactlyOnce semantics until or
> unless the aggregate store of
> unprocessed messages exceeds some threshold.
>
> Would I want that level of assurance for deposits to my bank account?
> Probably not. However,
> I suspect that there are probably quite a few applications for which a
> best effort with duplicate
> detection (AtMostOnce) would be more than adequate to the task.
>
> Cheers,
>
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email:
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
>
> "Yalcinalp, Umit" <> wrote on 07/25/2005 10:11:55
> PM:
>
> > It seems to me that the important use case to acknowledge as DA
> between
> the RMD and AD is "exactly
> > once" semantics. We are discussing what types of DAs need to be
> exposed
> and be known by a client
> > application, not the interaction between RMD and RMS. Therefore, it is
>
> important to discuss what
> > DAs need to be exposed as agreed between RMD and AD which will also
> affect an application client's
> > choice/behaviour.
> >
> > At most once esp. when the messages are permitted to be dropped on the
>
> "floor" does not make sense
> > as one would not bother with using RM. When one does not allow the
> messages to be dropped but also
> > required them tobe delivered only once, you end up with exactly once
> semantics. I believe this is
> > also Chris's point.
> >
> > From an application client's point of view, it is important to know
> that
> the DA for exactly once
> > is obeyed even if it is only as "observed" assurance. For example, one
>
> may care that an endpoint
> > is reliable and the RMD will deliver the messages exactly once to
> accomodate a debit (or credit)
> > message of a bank account. This type of DA may be used for choosing an
>
> endpoint (As an example, I
> > would not personally choose an endpoint for my bank which had
> at-most-once DA for credit messages
> > since my deposits may be gone to no man's land :-). As a matter of
> fact,
> I would change my bank if
> > the bank advertised reliable message delivery but could only advertise
>
> at most once behaviour. For
> > me, it is not reliable, period).
> >
> > Cheers,
> >
> > --umit
> >
> >
> >
> >
> >
> > From: Jacques Durand [mailto:]
> > Sent: Monday, Jul 25, 2005 6:51 PM
> > To: 'Christopher B Ferris'; wsrx
> > Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once" delivery
> assur ance
>
> > Let us wait for Ashok to clarify this (Ashok, have we put enough words
>
> in your mouth yet :-) ?
> > I think we agree that some aspect of the protocol would be useless for
>
> just AtMostOnce, but I'd
> > argue that the notion of sequence and seq number is quite important
> for
> implementing an efficient
> > duplicate check - so even if no Ack nor resending is needed, I'd say
> it
> is valuable to use this
> > part of the protocol (meaning the sequence creation and usage).
> > -Jacques
> > -----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
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
>
