[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Issue i005
I will second it. I think its good. Duane Christopher B Ferris wrote: >Duane, > >I haven't raised it as a formal issue yet... was trying to guage interest. >Clearly, I think it would be >a good idea. :-) > >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 > >Duane Nickull <dnickull@adobe.com> wrote on 08/25/2005 06:14:57 PM: > > > >>+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]