[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once" delivery assur ance
AtMostOnce DA between the RMD and the AD seems to be wasteful at the first glance. The hunch here may be that all the efforts spent by the RMS and the RMD in ensuring the on-wire AtLeastOnce semantics do not necessarily obligate the RMD to deliver all the messages to the AD! I can however imagine use cases where this apparent wastage may be justified. For example, it is possible that the Source and the Destination may have a business agreement that specifies when and which messages the RMD is allowed to drop and the Source will be billed only for those messages that are delivered to the AD. Now what is not clear to me is - whether the RM layer is allowed to utilize the AtMostOnce DA in dealing with abnormal situations inside the RM layer (e.g. low resource conditions/cataclysmic event). Resorting abruptly to AtMostOnce DA upon facing a cataclysmic event may not be permissible in all the cases. The RMD may be required to either report a failure or respect whatever DA is already established between the RMD and the AD. When the RMD reaches certain thresholds of resource utilization, it may want to notify the RMS about the situation with the hope of getting some breathing time for recovery. The current design provides for this to some degree via the ExponentialBackOff policy assertion. I am not entirely sure if this static policy assertion is enough or whether a more robust mechanism needs to be baked into the protocol that allows for the RMD to dynamically push back on RMS to slow down or stop (re)transmitting messages in the low-resource like situations. I will raise a issue formally for tracking purposes. Thanks, Sanjay >-----Original Message----- >From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] >Sent: Tuesday, Jul 26, 2005 9:14 AM >To: Bergersen, Rebecca >Cc: Bergersen, Rebecca; wsrx >Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once" >delivery assur ance > >Now, for my comments. > >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 > >"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'. > >I never claimed that it did. > >> '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'. > >Okay, I'll agree with that characterization as to what it >*means*. But in >practice, >it is used to imply best effort coupled with duplicate detection. > >> 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. > >When I think of ExactlyOnce, I think of it as meaning, "short of some >cataclysmic >event in which either the RMD or AD can not be recovered, or >in which the >AD is decommissioned, the message will be delivered". > >> >> 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' > >As I have said before, the DA is not reflected in the protocol at all. >It is a function of the contract between the RMD and AD (and possibly >between the AS and RMS). > >> 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. > >Which gets back to why I think that in the context of RM, best >effort IS >implied for AtMostOnce. Otherwise, I would agree. > >> >> 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]