RE: [ws-rx] i023 proposed resolution

["Patil, Sanjay" <sanjay.patil@sap.com>]

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
>