I see AckInterval as just an example of
what I would call RMD “optional behavior indicators” that
are sent back on the CSR, some other example being /Expires, /IncompleteSeqBehavior,
Shouldn’t we have a consistent
policy regarding these – I guess the only reason we actually may need any
of these in the protocol, is that an out-of-band (static) agreement would not
be able to accommodate dynamic conditions – e.g. varying from sequence to
sequence based on resource availability.
Given this I’d consider AckInterval
as a indicator for the RMS as valuable as any other, in some
situations (even if an outofband general agreement was stating the ack policy).
Looks to me that Option #1 is most useful to RMS, in this perspective.
Jacques
From: Christopher B
Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, June 22, 2006 3:54
AM
To: Doug Bunting
Cc: Bob Freund-Hitachi; Doug
Davis; Doug.Bunting@Sun.COM; ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] i130 - what
does ack interval refer to
IMO, Option 1 was the intended meaning... the interval
following receipt of a message
before
an Ack is sent.
Thus,
an RMS could guage whether it might want to retransmit a message if, after the
ackInterval
had
elapsed, it had not seen an ack for a message that it had just sent. Its
purpose was also to allow
for
optimization of acks, such that in the case where there are multiple messages
received within
the
interval, the RMD could bundle up a "number of acks" into a single
SeqAck, conserving
bandwidth.
That
said, I think Bob's characterization below is about right regarding the fact
that we really don't
need
it at all, and I would certainly support option 3.
One
last clarification, just in case some of what was stated makes it into
clarified text
(should
we choose to keep it), the original note in this thread had the following:
> >
Option 1 means that the RMD will wait no longer than the AI value
> > before it sends an Ack. The
> > RMS can be assured that if it doesn't
get an Ack from the RMD after
> > that time then the Ack
> > was lost. Note: a new msg into the
RMD initiates the timer and the
> > sending of an Ack stops it.
Actually,
it would be more like:
Option 1
means that the RMD SHOULD wait no longer than the AI value
before it sends an Ack after receiving a message.
The RMS can assume
that if it
doesn't get an Ack from the RMD after
the AI has elapsed following the transmission of a
message from RMS to
RMD, then
there is a probability that the message was
unsuccessfully
transmitted and hence, the message SHOULD be retransmitted.
The RMD is
always free to send an Ack anytime before the AI has elapsed.
Cheers,
Christopher
Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
Doug.Bunting@Sun.COM
wrote on 06/21/2006 11:12:16 PM:
> Sorry, I missed this email before sending my
last message.
>
> OK, we have option 3: Eliminate the acknowledgement
interval from the
> specification.
>
> As Doug knows, I was having trouble finding a
compelling purpose for
> this value from an RMS perspective.
Perhaps, a hint for the RMS Make
> Connection interval?
>
> I was also thinking option 3 effectively
re-opens an old issue but
> didn't go looking...
>
> thanx,
> doug
>
> On 21/06/06 18:46, Bob Freund-Hitachi wrote:
> >
> > There were previous arguments concerning
ack interval. At that time I
> > was one that argues that it was
unnecessary since efficient
> > implementations, from a latency point of
view, would immediately ack
> > and that ack range could be used as an
optimization based on system
> > load if there were more than one message
to ack at the point when the
> > ack was to be sent. Others argued
that the ack interval could be used
> > as a “hint” to either create
more opportunities for this optimization
> > or to allow perhaps ack piggybacking on
response. In both of these
> > arguments it would need to be the time
that the acknowledger would
> > hold-off from sending the
acknowledgement simply to permit such an
> > optimization to occur. I still
maintain that this is ill advised and
> > an unhelpful feature. But it is
consistent with your case 1.
> >
> > The second alternative that you discuss
is not discussed as far as I
> > remember.
> >
> > I suggest that clarification is best
performed by eliminating the feature.
> >
> > Thanks
> >
> > -bob
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> > *From:* Doug Davis
[mailto:dug@us.ibm.com]
> > *Sent:* Wednesday, June 21, 2006 9:32 PM
> > *To:* ws-rx@lists.oasis-open.org
> > *Subject:* [ws-rx] i130 - what does ack
interval refer to
> >
> >
> >
> >
> > All,
> > Doug Bunting and I have been
discussing issue 130 ("what does ack
> > interval refer to")
> > and we've hit a bit of a roadblock.
There are two (perhaps more) ways
> > of interpretting
> > what the AckInterval (AI) value is meant
to be used for, or what its
> > intended meaning is supposed
> > to be. The two, most likely,
options are:
> > 1 - the maximum time the RMD will wait,
after receipt of a message,
> > before an Ack will be sent
> > 2 - the maximum time the RMD will wait
before between sending Acks
> >
> > Option 1 means that the RMD will wait no
longer than the AI value
> > before it sends an Ack. The
> > RMS can be assured that if it doesn't
get an Ack from the RMD after
> > that time then the Ack
> > was lost. Note: a new msg into the
RMD initiates the timer and the
> > sending of an Ack stops it.
> >
> > Option 2 means that the RMD will send
out an acknowledgement, at
> > least, every AI milliseconds.
> > Sort of like a heartbeat. The RMS
can be assured that it will not
> > need to wait any longer than the
> > AI before an Ack will be resent.
Note: the sending of an Ack will
> > reset the timer and it will only stop
> > upon termination of the sequence.
> >
> > Note: in both options the RMD is always
free to send more acks and the
> > RMS is always free to
> > send an AckReq - but we're not worried
about those situations.
> >
> > The current wording is a bit
ambiguous.So, the question for the TC
> > is....which option do we
> > want to present in the spec?
Thoughts?
> >
> > thanks,
> > -DougD
> >