[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Issue i005
+1 - This covers it perfectly IMO. Chris - has your other proposal for optimization been accepted yet? D Christopher B Ferris wrote: >As I mentioned on the call, I think that what needs to be said in the spec >could be most constraining on the >RMD perspective. > >Proposal: > >An RMD MUST NOT issue a <SequenceAcknowledgement> containing a <Nack> for >a message(s) that >it has previously acknowledged within an <AcknowledgementRange>. > >An RMS SHOULD ignore a <SequenceAcknowledgement> containing a <Nack> for a >message(s) that >has previously been acknowledged within an <AcknowledgementRange>. > >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 > >"Winkler, Steve" <steve.winkler@sap.com> wrote on 08/25/2005 04:19:31 PM: > > > >>Hi Doug, >> >>As I mentioned, the actual wording can be left to the editors as long as >> >> >the semantics have been > > >>agreed upon. The proposal was sent simply as a starting point for >> >> >discussion. My interpretation > > >>of the spec as it stands is that a nack can be ignored. The proposal >> >> >was to add words to state > > >>that messages should be retransmitted in response to a Nack, but given >> >> >that nacks are intended > > >>only for performance optimization, I don't think that this behavior >> >> >should be required. I do > > >>think, however, that we should encourage 'better' implementations that >> >> >follow recommended > > >>optimization practices unless a specific implementation instance has >> >> >sufficient reason not to. > > >>Cheers, >>Steve >> >> >> >>From: Doug Davis [mailto:dug@us.ibm.com] >>Sent: Thursday, Aug 25, 2005 12:59 PM >>To: Winkler, Steve >>Cc: Marc Goodner; ws-rx@lists.oasis-open.org >>Subject: RE: [ws-rx] Issue i005 >> >> > > > >>The wording seems a bit backwards to me. I think that retransmission >> >> >upon receipt > > >>of a NACK is required except when the message as been previously ACKd. >> >> >The text > > >>as stated implies that a NACK can be ignored even when its has not been >> >> >ACKd. > > >>(Why do I feel like Bill The Cat :-) >> >>I'd prefer something more like: >> >>An RM Source MAY choose to not retransmit the message corresponding to >><Nack> element in cases where it previously received an acknowledgement >> >> >for > > >>that message. >> >>Although, I also see no reason to not go one more step and say that the >> >> >RMS > > >>should always ignore the NACK in those cases too. But this isn't a bad >> >> >compromise. > > >>thanks, >>-Doug >> >> >> >> > > > >>"Winkler, Steve" <steve.winkler@sap.com> >>08/25/2005 02:16 PM >> >>To >> >>"Marc Goodner" <mgoodner@microsoft.com>, <ws-rx@lists.oasis-open.org> >> >>cc >> >>Subject >> >>RE: [ws-rx] Issue i005 >> >> >> >> >> >>Hi Marc, >> >>The more compact wording is fine with me with the exception that you've >>changed the SHOULD to a MAY. I personally like the stronger wording, >>but understand that it is an optional performance enhancement. I think >>the semantic difference between SHOULD and MAY should be decided by the >>TC. >> >>I also think that we may need to investigate the ability to advertise >>the ability for destinations to trigger retransmissions with Nacks as a >>policy. I'll look into this a little more and possibly raise a separate >>issue to address this. >> >>Cheers, >>Steve >> >> >> >> >> >> >> >>>-----Original Message----- >>>From: Marc Goodner [mailto:mgoodner@microsoft.com] >>>Sent: Thursday, Aug 25, 2005 9:58 AM >>>To: Winkler, Steve; ws-rx@lists.oasis-open.org >>>Subject: RE: [ws-rx] Issue i005 >>> >>>Steve, >>> >>>I propose the following more succinct wording to be used at >>>Section 3.2, >>>after line 338 in place of what you have proposed below. >>> >>>"The RM Source MAY retransmit the message corresponding to the <Nack> >>>element when it has not already received an acknowledgement for that >>>message." >>> >>>-----Original Message----- >>>From: Winkler, Steve [mailto:steve.winkler@sap.com] >>>Sent: Thursday, August 18, 2005 2:11 PM >>>To: ws-rx@lists.oasis-open.org >>>Subject: [ws-rx] Issue i005 >>> >>> >>> >>>Issue i005 was originally brought up at the F2F, not >>>necessarily by me, >>>but I was an active part of the discussion and therefore would like to >>>continue that discussion on the list. I've included some background >>>information to expound upon the description and I've followed with a >>>concrete proposal that I hope the TC will consider as a starting point >>>for resolving the issue. >>> >>>Cheers, >>>Steve >>> >>> >>>Background >>> >>>The asynchronous nature of acks, as well as line 336/337 of the spec >>>indicate that 'The RM Destination MAY send a <SequenceAcknowledgement> >>>header block at any point.' In certain cases, this could result in an >>>Ack for a given message overtaking an Nack for the same message. The >>>rationale given for the Nack is that the gap analysis can be performed >>>on the RMD side resulting in performance enhancements (see lines >>>376-378). In the case that the Nack overtakes an Ack, the Nack could >>>actually go against the spirit of the spec and result in performance >>>degradation by triggering the retransmission of a message that has >>>already been received by the RMD. It should be noted that receipt of >>>this message by the RMD a second time is in no way an error, >>>but simply >>>an unnecessary inefficiency in the protocol for this edge >>>case. Better >>>implementations would have probably avoided this anyway. >>> >>>Several people during the discussion at the F2F mentioned >>>that there may >>>be some benefit in Nacking a message to trigger resending of a message >>>that has already been received by the RMD. Whereas I can see >>>that this >>>may be true, it seems like this kind of functionality would need to >>>happen at a layer above RM (i.e. it's out of scope for this spec). >>>However, given that messages can be delivered multiple times >>>anyway, it >>>would not be the end of the world to retransmit a message that has >>>already been delivered to the RMD. Therefore I would not want to >>>preclude an implementation that wants to '(ab)use' this fact >>>from being >>>allowed to use the RM machinery already in place to achieve this. >>> >>>I also noticed while investigating this issue that there >>>doesn't seem to >>>be any explicit indication in the spec that a Nack message should >>>trigger the resend of a message. I believe that this is implied, but >>>since it's an optimization, it is also most likely not >>>intended to be a >>>requirement. >>> >>>Proposal: Add text to the spec to explicitly state what an >>>RMS should do >>>when it receives a Nack message and tighten the spec for the edge case >>>described above in the following manner (wordsmithing can be >>>done later, >>>but you get the gist): >>> >>>In Section 3.2, after line 338 add something like this: 'If the RM >>>Source should receive a <SequenceAcknowledgement>containing a >>>Nack, the >>>RM Source SHOULD retransmit the message corresponding to the >>>Nack. After >>>the notification of successful receipt of a given message by the RM >>>Destination, the RM Source SHOULD NOT attempt to retransmit >>>the message >>>in the event that it receives a negative acknowledgement for it at a >>>later point in time.' >>> >>> >>>------------------ >>>Steve Winkler >>>SAP AG >>> >>> >>> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]