Re: [ws-rx] Issue i005

[Christopher B Ferris <chrisfer@us.ibm.com>]

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
> >>>
> >>> 
> >>>
> >
> > 
> >