[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] NEW ISSUE - No indication of how to process NACKs in normal case
+1 Thanks, Sanjay WS-RX TC Member >-----Original Message----- >From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] >Sent: Wednesday, Sep 07, 2005 10:55 AM >To: Christopher B Ferris >Cc: Marc Goodner; Winkler, Steve; ws-rx@lists.oasis-open.org >Subject: Re: [ws-rx] NEW ISSUE - No indication of how to >process NACKs in normal case > >Assuming that the Sequence hasn't failed or closed, RMS MUST >retransmit >all the messages that have not been ACKed (timing of those is upto the >RMS). This may happen due to timeout on the RMS side, receipt >of an ACK, >receipt of a NACK or the phase of the moon. From that perspective NACK >is a very good optimization and most implementations, I suspect, will >retransmit on receiving a NACK (except for special cases such >as the RMS >being overloaded, special optimization requirements, special >agreements >between RMS and RMD. mobile environment, etc). > >Nevertheless, including a MUST does not seem appropriate -- >since it is >possible that a ACK is received right after a NACK and the RMS decides >(correctly) not to retranmit the message. > >-Anish >-- > >Christopher B Ferris wrote: >> I disagree. >> >> A Nack is an optimization of an Ack with gaps, true. >However, if the RMD >> is issuing Nacks >> (it's choice) then to ensure the correctness of the >protocol, the RMS MUST >> retransmit the >> messages, just as it MUST retransmit unacknowledged messages >as expressed >> as a >> SequenceAcknowledgement with more than one >AcknowledgementRange elements. >> >> What is not specified, nor should it be, is the timing of the >> retransmission. >> >> 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 >> >> "Marc Goodner" <mgoodner@microsoft.com> wrote on 09/07/2005 >12:28:17 PM: >> >> >>>Because this is up to the RMS and is only an optimization the RMD may >>>use a MAY seems more appropriate here than either a SHOULD. A MUST is >>>not acceptable, a SHOULD is. I think Steve's rationale for proposing >>>this as a SHOULD based on previous discussion of this topic >was correct. >>> >>>-----Original Message----- >>>From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] >>>Sent: Wednesday, September 07, 2005 9:25 AM >>>To: ws-rx@lists.oasis-open.org >>>Subject: RE: [ws-rx] NEW ISSUE - No indication of how to >process NACKs >>>in normal case >>> >>>+1 >>> >>>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 >>> >>>"Winkler, Steve" <steve.winkler@sap.com> wrote on 09/07/2005 12:09:18 >>>PM: >>> >>> >>>>Hi Doug, >>>> >>>>I went back and forth on that one myself for a little >while. I prefer >>> >>>MUST too, but there appeared >>> >>>>to be some push back on this during the initial discussion >so I stuck >>> >>>with SHOULD. Your rationale >>> >>>>makes sense to me though and I would be fine (even happy) >to use MUST. >>> >>>Let's see what the group >>> >>>>thinks on the call on Thursday. >>>> >>>>Cheers, >>>>Steve >>>>-----Original Message----- >>>>From: Doug Davis [mailto:dug@us.ibm.com] >>>>Sent: Wednesday, September 07, 2005 6:37 AM >>>>To: ws-rx@lists.oasis-open.org >>>>Subject: Re: [ws-rx] NEW ISSUE - No indication of how to >process NACKs >>> >>>in normal case >>> >>> >>>>Steve, >>>> +1 - although I'd prefer it to be a MUST to be consistent >with the >>> >>>text for AckRequested - but >>> >>>>since its really up to the RMS to determine when to do it anyway its >>> >>>not >>>a huge thing. >>> >>>>thanks >>>>-Doug >>>> >>>> >>> >>>>"Winkler, Steve" <steve.winkler@sap.com> >>>>09/06/2005 02:54 PM >>>> >>>>To >>>> >>>><ws-rx@lists.oasis-open.org> >>>> >>>>cc >>>> >>>>Subject >>>> >>>>[ws-rx] NEW ISSUE - No indication of how to process NACKs in normal >>> >>>case >>> >>>> >>>> >>>>All, >>>>Here's a description of the new issue I wanted to raise from the >>> >>>discussion of the related issue i005 [1]. >>> >>>>Title: Processing model of NACKs >>>>Description: Although it is assumed that a NACK will trigger >>> >>>retransmission of a given message >>> >>>>from the source to the destination there is no wording in >the current >>> >>>version of the spec that >>> >>>>describes this feature adequately. >>>>Justification: This will clarify to implementers the spriit of the >>> >>>spec >>>by spelling out in more >>> >>>>concrete terms what is currently only implied. >>>>Target: Core >>>>Type: Design >>>>Proposal: >>>>Add the following to the spec directly before the text that is >>> >>>incorporated as a resolution to i005: >>> >>>>Upon the receipt of a Nack, an RM Source SHOULD retransmit >the message >>> >>>identified by the Nack as >>> >>>>soon as possible. >>>>Cheers, >>>>Steve >>>> >>>>[1] http://lists.oasis-open.org/archives/ws-rx/200508/msg00272.html >>>> >>>>--------------------------- >>>>Steve Winkler >>>>SAP AG >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]