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] Proposal for closure of Issue i022, RM Assertions


I do, but I’m not worried about the scope of impact here particularly in light of the issues Umit filed last week. I prefer closing this issue as Bob has proposed and look forward to seeing the issue he is proposing filing on retransmission parameters in general. If there are open points from the justification below that need to be discussed that’s the context I would prefer to have it in.

 

There is already an issue filed on InactivityTimeout, i055, that I think is sufficient in combination with i056 on the value. Obviously i056 would only have one parameter left to discuss, but I don’t see a problem with that.

 

I think we can wrap this one up now and just don’t see a need for any more issues around it than the one Bob has already proposed filing.

 


From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
Sent: Monday, October 24, 2005 12:42 PM
To: Marc Goodner; Bob Freund; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Proposal for closure of Issue i022, RM Assertions

 

 

Issue i022 identifies a set of problems associated with the bulk of RM assertion parameters including retransmission parameters. It's possible that Bob's proposal if accepted would make some of the problems identified by i022 irrelevant. However, there are other aspects of i022 (such as default value, definition and applicability of InactivityTimeout) that may not be fully addressed by Bob's proposal.

 

There are at least two ways we could go forward: a> Split i022 into two new issues. One that speaks about retransmission parameters and the other that talks about the remaining parameters. Bob's proposal could be discussed in the context of the first child issue. b> Create a brand new issue that discusses the utility of retransmission parameters and make i022 (and several others: 23, 54, 56, etc) dependent upon it. We could schedule the new issue for resolution before the dependent issues thus automatically adjusting the scope of the dependent issues.

 

I prefer the option b> above. Marc, would you be opposed to opening such a new issue? I thought you always liked smaller, focused issues! 

 

Thanks,

Sanjay 

 


From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Monday, Oct 24, 2005 11:53 AM
To: Patil, Sanjay; Bob Freund; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Proposal for closure of Issue i022, RM Assertions

I don’t believe we need another issue for why they aren’t necessary. Bob has done a good job explaining that here.

 

As far as major impact to the assertion I disagree. These were optional parameters and were intended to be used as “hints” only. If this proposal is accepted I think it is easy enough to point to the resolution of i022 to justify closing i054 with no action.

 


From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
Sent: Monday, October 24, 2005 11:46 AM
To: Bob Freund; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Proposal for closure of Issue i022, RM Assertions

 

 

Hi Bob,

 

As others have also suggested, would you be willing to open a seperate issue that provides justification for why the retransmission parameters are unnecessary. Accepting the stated proposal below (removal of the retransmission parameters) may effect substantial changes in the RM policy specification and may possibly make a few other issuses moot. It will be good to have a dedicated new issue for tracking such large scale changes.

 

Thanks,

Sanjay

 


From: Bob Freund [mailto:bob.freund@hitachisoftware.com]
Sent: Friday, Oct 21, 2005 5:11 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] Proposal for closure of Issue i022, RM Assertions

Argument:

Retransmission parameters as well as algorithms are problematic for the following reasons:

1)       The characteristics of the path from source to destination are often unknown and often are time-variant.

2)       Retransmissions if too frequent cause flooding and potential catastrophic degradation if the path is near saturation

3)       The path may consist of not only transmission means, but also intermediaries with attendant processing delays

4)       Exponential back off may be implemented many ways, there is more than one algorithm that use different parameters

5)       Back off algorithm selection may be implementation specific, what is good for cell phones may not be good for cluster interconnected nodes or crossbar connected multiprocessors

6)       I have found no theoretical modeling published concerning stability of specific back off algorithms which consider the case of web services cum intermediaries

7)       Most published data concerning the behavior of back off algorithms examine fairly simple network segment related saturation and do not address client, server, let alone intermediary saturation.

8)       Exponential back off algorithms need an adaptive recovery mechanism for those situations where there is a high standard deviation of delay.

9)       TCP/IP experience has shown that efficiencies are improved with an adaptive mechanism as described in TCP Extensions for High Performance (see RFC 1323 RTTM)

Proposal:

Clearly a back off mechanism is required; however implementation specific needs are not served well by the specification of any specific algorithm for all potential implementations of WS-RM.  It is recommended that implementers utilizing IP based transmission media consider the mechanism described in RFC 1323.  In additions, acceptance of this proposal removes all mention of re-transmission which is a required for correct operation of the protocol. These however are beyond the scope of the issue as stated.

Therefore:

Delete all re-transmission parameters as described in the WS-RM Policy specification [1] since they are unnecessary and unhelpful should the implementer use an algorithm with a different set of controls.

 

Note:

A new issue should be opened to address the location and manner by which re-transmission behavior is specified.

 

Thanks

-bob

 

Specific modification to documents:

In [1]

Delete lines indicated with cross-out in the attached document,

Adjust portions highlighted in attached document to reflect line number modifications resulting from deletions

 

References:

[1] WS-RM Policy WD DTD 2005-10-19



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