RE: [ws-rx] Issue i005

[Doug Davis <dug@us.ibm.com>]

Perhaps its all a matter of perspective
but I view a NACK much in the same way I view AckRequested.  For AckRequested
the spec says: 
  An RM Destination that receives
a message that contains an <AckRequested> header block MUST respond
with a message containing a <SequenceAcknowledgement> header block.
It doesn't really say anything about
when this SeqAck is sent - as with your comments below about when a retransmission
occurs, I view an AckRequested as a hint, or perhaps a "nudge",
to the RMD to speed-up the process of sending back a SeqAck, but only if
it makes sense.
So, going back to NACKs.... to me a
NACK is the RMD's way of asking the RMS for this particular message - again,
like a "nudge" to the RMS to speed-up the resending of it.  While
I definately do understand why some people think of it, sort of, as a no-op
because a retransmission will happen anyway - if the spec doesn't have
this nudge-factor then I question the entire point of having NACK at all.
 The spec says:
  The <Nack> element permits
the gap analysis of the <AcknowledgementRange> elements to be performed
at the RM Destination rather than at the RM Source which may yield performance
benefits in certain environments. 
  But, since the receipt of a NACK
does not say anything about any other message # - meaning if there were
no SeqAcks at all and just a NACK then without the nudge-factor all messages
would be treated equally w.r.t. retransmission so what was the point of
sending the NACK?
IMO, we should either make NACK a nudge
to the RMS to retransmit or we should drop it entirely.  And I'm leaning
towards the nudge.  (ok I just like saying nudge  :-)

thanks
-Doug

"Giovanni Boschi" <gboschi@sonicsoftware.com>

08/25/2005 08:00 PM

To	"Winkler, Steve" <steve.winkler@sap.com>, Doug Davis/Raleigh/IBM@IBMUS
cc	"Marc Goodner" <mgoodner@microsoft.com>, <ws-rx@lists.oasis-open.org>
Subject	RE: [ws-rx] Issue i005

My interpretation of the spec
as it stands is also that a Nack may be ignored, and I think that is a
good thing.
 
Let me phrase it differently:
 what behavior can the RMD reliably expect to *observe* from
the RMS as a result of the RMD sending the RMS a Nack?  The answer
is simple: Nothing.  And no language or semantics we discussed today
would change that - the reason is that the Nack itself is unreliable, and
it may never make it to the source at all.  And, of course, even if
the Nack does make it to the RMS, the resend may not make it to the RMD.
 So, fundamentally, the RMD can hope for, but cannot expect, to receive
a copy of the message in response to a Nack.  Given that the RMD cannot
depend on it, it can’t possibly be an interop issue, and I see no reason
not to allow the RMS to ignore it, in effect behaving as if it never saw
it, for its own reasons.  And it may have some very good reasons,
some of which I’ll mention below.
 
The question came up as to
whether this is testable behavior, and I would maintain that it is not
– at first it appears testable, if only in a contrived enviroment where
the entire transport distance maintains order and does not lose messages
– that is, only in an environment where the whole point of WSRM is moot.
 But then, of course, messages would not be lost or reordered, so
why would the RMD be sending a Nack in the first place?  Ignore that
for a minute, and assume that the RMD did send a Nack, and did receive
a message soon thereafter;  how does it know that it was resent as
a result of the Nack and not due to the regularly scheduled retransmit
interval?
 
Regarding the intent to “encourage
'better' implementations that follow recommended optimization practices”,
what are the grounds for assuming that resending immediately is a “better”
optimization?  What, after all, is being optimized?  Is it latency?
 Transmission costs?  Disk space at the RMD?  What if the
RMS knows that its next scheduled retransmit interval is 10ms away and
would rather just wait?  What if the RMS simply cannot retransmit
because it needs to wait for its next satellite uplink window which is
10min away?  What if the RMS is operating at the bandwidth threshold
of its network SLA, and the premature retransmit will cost it billable
dollars at overage rates?  In my experience, there is no reason to
assume that RMS and RMD, particularly if they belong to different organizations,
are going to be interested in optimizing the same thing.
 
The proposal would hand over
control of retransmit policy entirely to the RMD, in the hope that it would
use it wisely - without any suggestion of what that means.  Consider
a half-duplex failure of the transport layer (e.g. a reverse proxy firewall
is down, or a satellite connected node has downlink but no uplink?), and
RMD can send to RMS, but not the other way around.  The RMS sends
a few times and gets no Acks, and starts backing off exponentially; and
then starts receiving regular, perhaps frequent Nacks from the RMD which
has no clue what is going on.  As proposed, the RMS would have to
cancel its backoff algorithm, and start retransmitting on every Nack, even
after it had concluded that it should back off because previous resends
had obviously not been successful.  Why is this good?  Or would
we then raise an issue to clarify that, in this specific case, the RMS
is allowed to ignore the Nacks?
 
I do not believe that using
the word “SHOULD” avoids the above issues – the definition of SHOULD
in RFC 2119, but more generally the use of any RFC2119 terminology, clearly
implies that the behavior is a “requirement” that should be met except
perhaps for niche situations, and I disagree strongly with that implication.
 The Nack is currently a hint; not a noop, but a hint, and the choice
whether to resend is entirely at the RMS’ discretion.  If the issue
is to clarify that fact, then the previous sentence, or anyone else’s
version, seems like it would do.  If the proposal is to make it a
binding contract on the RMS, I would strongly oppose it, for all the above
reasons.
 
G.

---

From: Winkler, Steve [mailto:steve.winkler@sap.com]
Sent: Thursday, August 25, 2005 4:20 PM
To: Doug Davis
Cc: Marc Goodner; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Issue i005
 
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
>