[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] DA and Protocol: is the date over?
Chris, i don't think your "elephant gun for a gnat" analogy is appropriate. timestamps usually are not useful for this case (AtMostOnce/InOrder with no retransmissions) because time can go backwards (at least once a year and upon administrative action). so, really, one needs sequence numbers. but, then, because of re-boots and devices with non-persistent clocks (e.g. printer), one needs sequence identifier to scope your sequence numbers. that, in turn, brings in sequence identifier establishment/tear-down handshake. by this time, you've got a very substantial chunk of the protocol. in any case, what if RMS's limited resources allow it to hold for retransmissions only messages sent in past 30 seconds? even with SOAP over HTTP as a transport, if all that happened was that listen() backlog limit was exceeded on the server, retransmissions are possible. is this use case out of scope? if not, full WS-RM machinery is needed to support it. in other words, "reliable" in "reliable messaging" is in the eye of the beholder. what's very little or no reliability for some is a lot of reliability to others. all of this said, i agree with you that DA is out-of-band as far as wire protocol is concerned. it's just that low/no retransmission availability use case is something to keep in mind. thanks, dan Christopher B Ferris wrote: Jacques, There's no doubt that there might be use cases for AtMostOnce delivery of messages *between* the RMS and RMD. However, as I recall someone (Umit?) saying either on the list or on IRC, that that isn't reliable messaging. I would agree. In fact, RM would be overkill, using an elephant gun to kill a gnat, especially if InOrder is not required. What possible purpose would an acknowledgement serve if the RMS didn't care that all of its messages were received, and if it were not doing retransmission of messages (because it didn't care one way or the other if the messages were all delivered)? Fire and forget is probably good enough for that use case. Ordered processing could be facilitated by inspecting timestamps and discarding messages that had a timestamp value less than the highest value already processed. Again, I think we need to keep in mind the separation of concerns that I mentioned in the F2F briefing. RM is concerned only with ensuring that messages are transmitted successfully from the RMS to the RMD. Period. While the source application may want that all of the messages be processed by the destination application, there is nothing that the RMD can do to ensure that guarantee. The destination application might be implemented as a separate, distributed component, and be taken off line (whether voluntarily or not) never to return, despite the fact that there are unprocessed, yet acknowledged, messages in the RMD's message store. The point of RM is to ensure that all messages transmitted by the RMS are successfully *received* by the RMD. The RMS is responsible to retransmit unacknowledged messages. The RMD is responsible for acknowledging receipt of each message so that the RMS can discontinue retransmission of successfully received messages. That is the extent of the scope of the protocol. It does just that one thing (recall Curly's Law [1]). It's purpose is to provide better QoS than can be achieved using TCP/IP alone (which itself has reliability characteristics built-in, but offers no guarantees about anything above the TCP/IP layer). The same applies at the IP layer, and so on, down the OSI seven layer cake. If the application wants some assurance that the destination application received and processed (or faulted) the message, then you need an application-level message for that (e.g. a business-level ack). The DA has relevance at the RMD as it specifies the QoS contract that the RMD offers the application destination. In the case of AtMostOnce, it is saying "look, I'll do my best to ensure that you get all of the messages, but I may have limited resources and you MAY lose some messages. You want a better guarantee than that, try another RMD provider.". [1] http://www.imdb.com/title/tt0101587/ 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 08/18/2005 03:08:31 PM:Since Anish opened this Pandora box, I must say I share his confusionabout the rationale forseparating the protocol mechanism from DA. That could well be the mother of all issues that we still need todiscuss on WS-RM, surelydeserving its own thread here (so I resubjected the mail). Chris may have some use cases or rationale for that, but we have notseen the detail of them yet.On my side, I can see the case of a monitoring device that only needsAtMostOnce for sending itsmeasures (maybe combined with InOrder), and that cannot afford aresending mechanism that it doesnot need, nor does it care about interpreting Acks. So the protocolwould be affected by DAhere... (note that even with AtLeastOnce, the tuning of resendingparameters depends on a Policyassertion, and we could make the case that such parameters can be seenas DA QoS parameters.)Anish, you are the one who started this... Jacques -----Original Message----- From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] Sent: Thursday, August 18, 2005 11:15 AM To: Jacques Durand Cc: 'Christopher B Ferris'; ws-rx@lists.oasis-open.org Subject: Re: [ws-rx] NEW ISSUE, twin sister of i019 Jacques Durand wrote:Chris: inline <JD> A meta-comment for those who may worry about the amount of discussion triggered by just one (or two) issues among... about 20 remainingissues?I think that behind the issues discussed here is a fundamental discussion touching at the protocol model and meaning of delivery assurance. There are many aspects of the model behind WS-RM that were not apparent for all TC joiners, and I guess that explains the understanding process (and questioning) going on.One of the problems I have had in the past (till Chris explained that the protocol is AtLeastOnce on the wire) was about Delivery Assurance and how/why it does/doesn't affect the protocol on the wire. The intention, as mentioned by Chris, that the protocol is AtLeastOnce on the wire is not apparent from reading the spec (at least to me). There are statements that contradict this or are misleading. For example, Section 2, 2nd para: "WS-ReliableMessaging provides an interoperable protocol that a ReliableMessaging (RM) Source and Reliable Messaging (RM) Destination use to provide Application Source and Destination a guarantee that a message that is sent will be delivered. The guarantee is specified as a delivery assurance. The protocol supports the endpoints in providing these delivery assurances. It is the responsibility of the RM Source and RM Destination to fulfill the delivery assurances, or raise an error. The protocol defined here allows endpoints to meet this guarantee for the delivery assurances defined below. " At the very least there is an editorial issue here. -Anish --Once that is being clarified and maybe refined, I certainly hope wewillnot need to go through this level of discussion at each issue... Jacques -----Original Message----- From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] Sent: Friday, August 12, 2005 5:30 AM To: ws-rx@lists.oasis-open.org Subject: RE: [ws-rx] NEW ISSUE, twin sister of i019 Jacques, Taking an approach of "what is not forbidden is allowed" inimplementing aspec will almost invariably lead to interoperability problems when applied to areas of the specthatprescribe what to do. <JD> I didn't pretend to make this my motto - but we all know thatthisis a question that every developer faces from time to time... I guess this is one of those areas where the keyword "SHALL NOT" can help alot.As to the point of using TerminateSequence on an incomplete Sequence,Idon't disagree that there is utility in providing a means for the RMS to terminate a Sequence.Thatis what the SequenceTerminated fault is for. Note that either endpoint may issue theSequenceTerminatedfault: Sequence Terminated This fault is sent by either the RM Source or the RM Destination to indicate that the endpoint that generates the fault has eitherencounteredan unrecoverable condition, or has detected a violation of theprotocoland as a consequence, has chosen to terminate the sequence. Theendpointthat generates this fault should make every reasonable effort tonotifythe corresponding endpoint of this decision. This leads us back to issue i019 unless we raise and resolve an issuethatsays roughly: is the RMS *required* to retransmit messages that are unacknowledged. <JD> mmmh, I never saw this as a key thing: retransmission - whether required or not - is a limited effort that can ultimately fail for whatever reason. Regardless of this effort, won't we inevitably face situations where there are gaps in the sequence that we have to live with till the end of the seq? But I think i019 stands regardless ofthis(see later). Note though that this changes the nature of the protocol significantly. My personal take on it is that the answer to the previous question is "yes" and that the only meaningfulwayof optimizing AtMostOnce DA with regards to messages on the wire (ifthatis what we want) is to permit the RMD to acknowledge messages that ithasnot received (e.g. pre-emptively filling in gaps) but that the RMS is still required to retransmit unacknowledged messages (just tokeepthe protocol simple). <JD> Chris: isn't that rather weird ??? I hope we don't need tostretchthe interpretation of acknowledgement (you seem to suggest that acknowledgement may have a different meaning depending on the DA in use). Note that i019 applies regardless of the DA in use: it only saysthat the RMS has no way to get an accurate account of *actually* received vs not-received messages at the time the Fault terminates thesequence on RMD (because the latest SequenceAck obtained by RMS mayshowunacknowledged messages for which we don't know what happened.) Thatcanstill be of great importance especially in the case of ExactlyOnce: knowing that a message was for sure never received by RMD, allows forameaningful failure notice to SA on which it can act (and I think it would also for AtMostOnce, since you are using ack mechanism theretoo).As long as accuracy of final ack status is considered a valid expectation, i019 is a valid issue IMO. </JD> That would effectively provide the protocol with the "forget before" that is needed in order to allow forsome messages to be dropped between the RMS and RMD without changing (and IMO significanltly over-complicating) the nature of the protocol. <JD> I think this is precisely the crux of this issue: do we want the RMS to forget which messages were not received for the sequence whenitterminates? (regardless on how it terminates) that seems to be thefirstquestion we need to address apparently. Cheers, Jacques Jacques Durand <JDurand@us.fujitsu.com> wrote on 08/11/2005 11:50:53PM:> Chris: > Maybe I am a bit obtuse here but I just did not take that whole statement itself in an exclusive > way (notwithstanding my notion of "complete" which was as good asindictionary.reference.com)... > I guess the "what is not forbidden is allowed" perspective. So Ithinksome editorial tightening > would help folks like me :-) > May I add, precisely because it is only about enabling RMD to efficiently reclaim resources > associated with the Sequence, I saw use cases where using <TerminateSequence> may be as > legitimate for an incomplete sequence as for a complete one. So Iguessthat is these use cases > that need be discussed - (let me download that Gil doc...) > Thanks, > Jacques > > -----Original Message----- > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] > Sent: Thursday, August 11, 2005 6:21 PM > To: ws-rx@lists.oasis-open.org > Subject: RE: [ws-rx] NEW ISSUE, twin sister of i019 > Jacques, > The spec says at line 569: > "After an RM Source receives the <SequenceAcknowledgement>acknowledging> the complete range of messages in a Sequence, it sends a element,inthe > body of a message to the RM Destination to indicate that theSequence is> complete, and that it will not be sending any further messagesrelatedto > the Sequence. The RM Destination can safely reclaim any resources > associated with the Sequence upon receipt of the message." > The key word in the first sentence is "complete", wherein thedefinition> of "complete" in this context is the fourth one here: > http://dictionary.reference.com/search?q=complete > 4. Absolute; total > I always thought that it was pretty unambiguous, but maybe I ammistaken> and it should instead read: > After an RM Source receives the <SequenceAcknowledgement>containing a> single <AcknowledgementRange> element with an @Upper valued at the > MessageNumber of the <LastMessage> in a Sequence and the @Lowervaluedat > "1". > That was certainly the intent. > The statement at 569 is followed up starting at line 580 with: > "/wsrm:TerminateSequence > This element is sent by an RM Source after it has receivedthe> final <SequenceAcknowledgement> covering the full range of aSequence.It > indicates that the RM Destination can safely reclaim any resources related > to the identified Sequence. This element MUST NOT be sent as aheader> block." > This reinforces what I claimed on the call, that the purpose of > TerminateSequence is to allow the RMD to reclaim any resources > associated with the Sequence. It means that the RMS is done, finit,kaput > with that Sequence. > I don't think that you should read into a spec, content which issimply> not there: > > I did NOT interpret it as: > > > > " an RM Source MUST NOT send <TerminateSequence> in other caseswhereit > has not received full > > acknowledgement of the complete range of messages in a Sequence."> But, maybe that is what is needed: > "An RM Source MUST NOT send a <TerminateSequence> if it has any > expectation of ever receiving information from the RM Destination > about that Sequence after the <TerminateSequence> is transmitted." > Again, the purpose of the <TerminateSequence> is to enable the RMDto> efficiently reclaim any and all respources associated with > the Sequence. It isn't necessary that the RMD ever receive thismessage,> as the resources can still be reclaimed either at the Sequence expiration > time or following a duration of inactivity, etc. However, the > <TerminateSequence> message's purpose seems clear, to me at least. > 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 08/11/200508:16:56 PM:> > Giovanni: > > > > I think you are right on the spot about the misunderstanding thatwehad > in the conf call today. > > Indeed, I interpreted this statement of the spec as nothing morethan> the normal use for > > TerminateSequence, non-exclusive of other uses: > > > > "After an RM Source receives the <SequenceAcknowledgement> acknowledging > > The complete range of messages in a Sequence, it sends a > <TerminateSequence> > > element, in the body of a message to the RM Destination toindicatethat > > the Sequence is complete, and that it will not be sending anyfurther> > messages related to the Sequence." > > > > I did NOT interpret it as: > > > > " an RM Source MUST NOT send <TerminateSequence> in other caseswhereit > has not received full > > acknowledgement of the complete range of messages in a Sequence."> > > > Therefore we were not discussing on the same base of premises. > > > > Your speculation is right: I assumed that seq termination (an operation > that is more meaningful to > > RMD than to RMS, given that the ending of a sequence has alreadybeen> notified by LastMessage > > sending ) may be appropriate in some cases where not all messageshave> been acked. My recent > > rewording of the issue clarifies this a bit, but is still basedon the> same interpretation of > > TerminateSequence, so I may need to shelve it and submit an issueon> TerminateSequence instead. > > > > Note: I believe your last paragraph below just illustrates theneedfor > clearly stating the valid > > use cases as in Gil doc, so that we can sync up on these beforeeven> discussing the issues ... > > > > Regards, > > > > Jacques > > > > -----Original Message----- > > From: Giovanni Boschi [mailto:gboschi@sonicsoftware.com] > > Sent: Thursday, August 11, 2005 3:47 PM > > To: Jacques Durand; ws-rx@lists.oasis-open.org > > Subject: RE: [ws-rx] NEW ISSUE, twin sister of i019 > > > > From the issue justification, "The specification is too lax onthe> > loophole that permits stray messages to > > "sneak-in" just before a termination, without any opportunity tobe> > acknowledged" > > > > This is what the specification says: > > > > "After an RM Source receives the <SequenceAcknowledgement> acknowledging > > the > > complete range of messages in a Sequence, it sends a <TerminateSequence> > > element, in the body of a message to the RM Destination toindicatethat > > the > > Sequence is complete, and that it will not be sending any further> > messages related to > > the Sequence." > > > > This, at least to me, says pretty clearly that a conformant RMSwillnot > > send TerminateSequence until all messages have been acknowledged,and> > that it will not send any new messages after sending TerminateSequence. > > > > To be sure, duplicates of messages previously sent (andacknowledged)> > may arrive at the RMD after TerminateSequence. But these are > > duplicates, not unacknowledged messages. > > > > The specification has a definition of "normal termination" which > > requires that all messages be acknowledged, and therefore the "situation > > whereupon normal termination of a sequence some messages thatwere> > previously send and never acknowledged..." is, by definition, > > impossible. The "accuracy of acknowledgments upon normalsequence> > termination" is 100% perfect. > > > > Now, during the call today, Jacques seemed to suggest that whatwas> > behind this is that a sender may need/want to terminate thesequence> > prior to all messages being acked; this may well have merit, orat the> > very least is worthy of discussion; the current spec clearly doesnot> > allow it, and it is well within the responsibility of the TC to consider > > such a change. > > > > But if the request is to change the definition of sequence termination, > > or maybe to provide an additional type of termination, the issue > > description should clearly say just that ("we should allow fornormal> > termination prior to acknowledgement of all messages"); butnothing in> > the text of the issue suggests that we are looking for a changein> > definition of normal termination. > > > > I don't know whether procedure allows revising the text of theissuefor > > clarity. As it stands now both the description and justificationbelow > > contain statements that appear to me to be factually incorrect,or at> > best highly misleading. It should not be surprising that this generates > > long discussions in the confcall about whether to even accept itas an> > issue. > > > > I will speculate that I may have an idea of what Jacques may beafter:> > a sender may, for a variety of reasons which we could discuss(e.g. it> > is being shut down for maintenance longer than the sequence expiration), > > be forced to stop resending; if so, it would be nice to knowwhich> > messages actually got delivered or didn't, so that it may sendthe> > undelivered ones again later in another sequence w/o duplicatingthem.> > AckRequested does not serve this purpose because, unless thesequenceis > > actually terminated, there may be more message out there inflightwhich > > will actually arrive at the RMD and be delivered. But I'm just > > speculating, the issue doesn't say that. > > > > Jacques, please clarify. > > > > Giovanni. > > > > ________________________________________ > > From: Jacques Durand [mailto:JDurand@us.fujitsu.com] > > Sent: Thursday, August 04, 2005 6:50 PM > > To: ws-rx@lists.oasis-open.org > > Subject: [ws-rx] NEW ISSUE, twin sister of i019 > > > > I realize that we should probably discuss this new issue in conjunction > > with i019, i.e. before closing on i019. > > (it is stating a similar problem, but for normal terminationcases.)> > > > Daniel: > > With the perspective of this new issue, I am leaning more towardyour> > proposal to mark as "last" the final sequence status. > > > > > > Jacques > > > > > > Title: Accuracy of acknowledgement status upon normal sequence > > termination > > > > Description: The specification does not address the situationwhereupon > > normal > > termination of a sequence, some message that were previously sentand> > never acknowledged > > (for which RM Source had stop any resending effort) has beenreceived> > late by RM Destination, > > e.g. between the sending of the last SequenceAcknowledgement and before > > the reception of > > a TerminateSequence message. This is the twin sister of issuei019which > > deals with a similar > > problem but in case of fault termination. > > > > Justification: Normal termination is actually a fairly commonevent> > (compared to sequence fault) > > and it is expected that sequences will be terminated even if theyhave> > missing messages. > > The specification is too lax on the loophole that permits stray messages > > to > > "sneak-in" just before a termination, without any opportunity tobe> > acknowledged. > > > > Target: core > > Type: design > > > > Proposal: A final acknowledgement status could be sent back that > > reflects the exact state > > at termination time. That could be done by sending (or by making > > available for polling > > even after the sequence is terminated) a lastSequenceAcknowledgement> > element, at the time > > the RM Destination terminates the sequence (either at receptionof> > TerminateSequence, > > or due to timeout). Such a SequenceAcknowledgement element shouldhavea > > "last" marker. > > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]