ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i023 proposed resolution
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Wed, 12 Oct 2005 21:19:26 -0400
+1
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
Jacques Durand <JDurand@us.fujitsu.com> wrote
on 10/12/2005 04:45:06 PM:
> Sanjay:
> I believe Flow control is a more general issue,
well identified
> otherwise, that needs to be addressed probably in a more general way
> (it is not just the RMD that may have trouble consuming messages
> fast enough, but the WS endpoint behind it, or the lower layers of
> the WS stack before.) It needs be addressed also when no reliability
> is required.
>
> >These assertions do not say anything about whether an RMS
> >should transmit new messages in a Sequence that already has many
> >existing unacknowledged messages.
> Keeping an eye on our primary objective of interoperability
of
> reliability techniques, that does not preclude implementing advanced
> inference schemes on either endpoint, e.g. RMS deciding that
> something is wrong and scaling back its resending, or notifying its
> AS, etc. As long as that does not require a specific protocol to be
> understood on both sides, it does not need be standardized.
> In a few words: I sympathize with the intent,
but think it is one of
> these issues that will be better understood after some time, and
> maybe then some aspect of it deemed in RM scope. For now, would
> close with no action.
> Cheers,
> Jacques
>
> -----Original Message-----
> From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
> Sent: Wednesday, October 12, 2005 12:05 PM
> To: Christopher B Ferris; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i023 proposed resolution
>
> Hi Chris,
> Some claification questions/comments inline below
...
> > -----Original Message-----
> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > Sent: Wednesday, Oct 12, 2005 10:03 AM
> > To: ws-rx@lists.oasis-open.org
> > Subject: [ws-rx] i023 proposed resolution
> >
> >
> > Regarding issue i023 [1], I believe that definition of
> > protocol mechanisms related to the proposed
> > resolution:
> >
> > "RM Protocol to support RMD pushing back on the RMS for
> > slowing down or
> > stopping (re)transmission of messages."
> >
> > When the WS-RM spec was initially published, there was an
> > accompanying white paper [2]
> > that made mention of a potential spec called WS-Transmission:
> >
> > "WS-TransmissionControl - A set of constructs for controlling
> > the exchange of
> > messages between services to improve reliability by
> > preventing message loss due to
> > service unavailability, overloading queues and other causes."
> >
> > Personally, I think that the issue of flow-control is
> > orthogonal to RM and really should be
> > addressed as a separate concern.
> What is the purpose of the RetransmissionInternval
and
> ExponentialBackoff assertions? Are these not configurations for
> flow-control to be used by the RMS when the RMD does not send Acks
in a
> timely manner?
> Should I interpret that the original spec authors
recognized the problem
> of overloaded RMD situations but they preferred a static policy based
> solution as opposed to a dynamic flow control solution that may
> introduce additional protocol elements?
> Also, the above referenced pair of assertions
seem to apply on a per
> message basis. These assertions do not say anything about whether
an RMS
> should transmit new messages in a Sequence that already has many
> existing unacknowledged messages. What is the point in sending new
> messages on a Sequence when the RMS has resorted to ExponentialBackoff
> for one or more existing messages in the same Sequence.
> It seems that a Sequence (or even higher) level
mechanism is needed to
> notify the RMS that the RMD is having issues with accepting messages.
> One solution may be to introduce pause/resume. Before dismissing this
> solution on the grounds of "this changes the protocol",
we should do a
> cost-benefit analysis. In case the TC concludes that pause/resume
is
> undesirable, then another option may to define a specific
> OverloadedFault upon receiving which the RMS should - a> stop sending
> new messages in that
> Sequence until b> ExponentialBackOff is triggered and all the pending
> messages are cleared.
> >
> > Proposal:
> >
> > I would propose that we close this issue with no action.
> I think we should wait a little bit further since
the TC has not yet
> been presented with the other options, specifically in the light of
the
> current RetranmsissionInterval/ExponentialBackoff based solution.
I am
> fine with either myself or someone from SAP owning and driving this
> issue (not for tomorrow's call though).
> Thanks,
> Sanjay
> >
> > [1]
> > http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.ph
> > p/14682/Re#i023
> > [2]
> > ftp://www6.software.ibm.com/software/developer/library/ws-rm-e
> > xec-summary.pdf
> >
> > 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
> >
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]