RE: [ws-rx] i023 proposed resolution

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: RE: [ws-rx] i023 proposed resolution

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
>