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] New Proposal for i056


Title: New Proposal for i056
What concerns me about your proposal is that there is nothing left other than RMS and RMD admins to pick up the phone and configure their two ends together. Of course, when you have the same vendor providing both, all of these wonderful tuning can be done in a non-interoperable fashion anyway.
 
I am quite curious as to what you think is the purpose of the policy document if there is nothing useful in it to indicate the configuration of the RM in conjunction with WSDL.
 
-1.
 
--umit
 


From: Bob Freund-Hitachi [mailto:bob.freund@hitachisoftware.com]
Sent: Thursday, Nov 17, 2005 12:50 PM
To: Yalcinalp, Umit; Bob Freund-Hitachi; wsrx
Subject: RE: [ws-rx] New Proposal for i056

You are correct.

AI is at best an early optimization since its sole purpose is to increase the frequency of piggy-backed acknowledgements and potentially acknowledgement range consolidation.  AI introduces acknowledgement delay in exchange for marginal RMS to RMS message traffic reduction.  I am sure that this might be useful for the extreme end of bandwidth limited deployments.  On the other hand, in heavy traffic situations queues may develop which if monitored could be used to achieve the same effect without artificially introducing acknowledgement delay in low traffic situations.  It is in heavy traffic or low bandwidth situations that AI may produce a marginal beneficial result.  IMO it still remains an optimization.

As long as implementation of AI remains optional, I have no fundamental objection to existence, however it best if it too were to be summarily defenestrated.

 

Revised proposal for complete resolution to i056:

Delete both IT an AI

Thanks

-bob

 


From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Thursday, November 17, 2005 12:31 PM
To: Bob Freund-Hitachi; wsrx
Subject: RE: [ws-rx] New Proposal for i056

 

Bob,

 

Even if you propose to delete IT, this does not take into account the use case we brought up for (b) for AI.

 

Issue i056 proposal contains RMS alignment with RMD with respect to AI as well. Please see the details below.  

 

In our opinion deleting IT does NOT resolve i056.

 

--umit

 

 


From: Bob Freund-Hitachi [mailto:bob.freund@hitachisoftware.com]
Sent: Thursday, Nov 17, 2005 12:21 PM
To: Yalcinalp, Umit; wsrx
Subject: RE: [ws-rx] New Proposal for i056

Counter proposal for closure:

Delete IT

Rationale

IT is evil

-bob

 


From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Thursday, November 17, 2005 11:37 AM
To: wsrx
Subject: [ws-rx] New Proposal for i056

 

Folks,

After some internal debate, this is our new position and new proposal for i056. This is an amendement to the proposal we are making before for this issue [1].

As you may know for i055, we are withdrawing our original proposal for defining ranges of IT values for the RMD, but we would like to retain that IT specified in the policy document that is attached to WSDL applies to RMD as indicated to an email sent earlier today.

Rationale for New Proposal for i056:

For RMS, the two values that the RMD's policy should specify will be of interest IT and AI and may require runtime adjustment. 

We consider two use cases:

(a) The configuration of RMD's IT affects the rate that RMS has to send the messages.  This is helpful when RMS has prior knowledge of the application's rate of generating messages.

Although, an application's rate of generating messages is an application concern, it affects the rate of an application to be able to send messages to an RMS. These application level concerns may be dictated by higher level standards or specifications in the spec, such as RozettaNet PIPs or simply prior knowledge that exists in the application in a vendor specific setting.

A mismatch would occur when the applications rate of sending messages is slower than the IT specified by the RMD.  In order to avoid sequence closure, RMS may try to retain a "sequence" activity with the priori knowledge that its own rate of sending messages is actually going to be less than the IT specified by the RMD.

In order to accommodate this use case, either the RMS has to send keep-alive messages or specify the IT on the RMD side.

We do prefer the latter since we do not want to architect keep-alive messages. In order to adjust its rate of sending messages, we believe that the RMS has to configure the RMD's IT so that RMD does not timeout before the RMS has the chance to send the next message in the sequence.

(b) The configuration of RMD's AI affects the way RMS will reclaim its resources as AI affects the rate of acknowledgements being received from the RMS side. Hence, RMS may be interested in configuring the RMD's AI parameter, at least within the boundaries of the range. (The spec has to assert clearly that AI is a range).

Hence if the RMS needs to have a AI which is less than the AI specifies by the RMD, it should be able to specify it accordingly. Basically, internal IT which is private to RMS must align with the RMD(AI).

If this alignment does not hold, the RMS may be claiming resources too early, and hence needs to adjust its IT to match with RMD (AI). In order to accommodate this, RMS should be able to transmit its own IT value to match the RMD(AI) and hence SET the value of RMD(AI) value.

We think that both of these use cases are essential for configuration of RMS and RMD and may be accomplished in a very simple manner. Further, we do not think that specifying the values of IT or AI need to be ranges, but "simple values" as currently specified in the specification. Therefore, this is a change from our previous proposal as well.

Here is the proposed text:

{Section XX: Optimization for specifying parameters within WS-RM Protocol

When RMS needs to specify the InactivityTimeout value for a sequence or specify the AcknowledgementInterval value for a sequence, the selection of the inactivity timeout {or Acknowledgement Interval} may be part of the create sequence protocol as specified in Section 3.4 of [WS-RM]. RMS MAY include the wsrmp:InactivityTimeout element {or the wsrmp:AcknowledgementInterval element} as a child of wsrm:CreateSequence element to designate the Inactivity Timeout {or Acknowledgement Interval} value.

<wsrm:CreateSequence ...>
<wsrm:AcksTo ...> wsa:EndpointReferenceType </wsrm:AcksTo>
<wsrm:Expires ...> xs:duration </wsrm:Expires> ?

<wsrmp:InactivityTimeout Milliseconds=600000/>
<wsrmp:AcknowledgementInterval Milliseconds=200000/>
</wsrm:CreateSequence>

This specific optimization may be rejected by the RMD and the RMD MUST use the CreateSequenceResponse Fault as the response to the Create Sequence request. In this case, the RMD MAY include the specified InactivityTimeout {or AcknowledgementInterval} element(s) as part of the [Detail] to indicate that the value specified by RMS is not valid.

}

We think that this is a very cheap solution which specifies an optimization extension and RMD that do not support this extension may reject the sequence with the specified methods that are already within the protocol.

Note that there is a small issue with respect to the CreateSequenceResponse Fault [2] that has been posted earlier that can be easily fixed to enable addition of [Detail] content.

Regards,

--umit

[1] http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i056
[2] http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml

----------------------

Dr. Umit Yalcinalp
Standards Architect
NetWeaver Industry Standards
SAP Labs, LLC
umit.yalcinalp@sap.com
Tel: (650) 320-3095



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]