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] i023 proposed resolution


Title: Message
+1
abbie
 
 
-->This is the Way  --> This is Nortel
-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Wednesday, October 12, 2005 9:19 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i023 proposed resolution


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