[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [ws-rx] NEW ISSUE: semantics of "at most once" delivery assur ance
oops, disregard the previous forward... THIS is the email Rebecca asked me to forward:-) 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 ----- Forwarded by Christopher B Ferris/Waltham/IBM on 07/26/2005 11:59 AM ----- "Bergersen, Rebecca" <Rebecca.Bergersen@iona.com> 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 > rebecca.bergersen@iona.com > ------------------------------------------------------- > 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:chrisfer@us.ibm.com] > 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: chrisfer@us.ibm.com > blog: http://webpages.charter.net/chrisfer/blog.html > phone: +1 508 377 9295 > > "Yalcinalp, Umit" <umit.yalcinalp@sap.com> 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:JDurand@us.fujitsu.com] > > 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:chrisfer@us.ibm.com] > > 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: chrisfer@us.ibm.com > > blog: http://webpages.charter.net/chrisfer/blog.html > > phone: +1 508 377 9295 > > Jacques Durand <JDurand@us.fujitsu.com> 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:chrisfer@us.ibm.com] > > > Sent: Monday, July 25, 2005 1:58 PM > > > To: ashok.malhotra@oracle.com > > > 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: chrisfer@us.ibm.com > > > blog: http://webpages.charter.net/chrisfer/blog.html > > > phone: +1 508 377 9295 > > > Ashok Malhotra <ashok.malhotra@oracle.com> 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:chrisfer@us.ibm.com] > > > > > Sent: Monday, July 25, 2005 1:08 PM > > > > > To: Doug Davis > > > > > Cc: Anish Karmarkar; tom@coastin.com; 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: 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]