OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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