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


Sanjay,

You might consider re-titling i022 “Value of transmission timing parameters” and be done with it, since I have proposed chucking the lot.

Retransmission parameters have no value as far as I am concerned; we have learned this the hard way in bi-sync, sdlc, fiberchannel, and TCP/IP not to mention others.  Perhaps I did not explain the justification of removing acknowledgementinterval. 

This is apparently an attempt to perform bandwidth optimization at the expense of protocol performance.  The protocol provides the native facility of multiple acknowledgements in a single message, in fact, the entire message history is acknowledged in each acknowledgement.  That is one aspect of this protocol that makes it somewhat insensitive to lost acknowledgements, since the next one will take up the slack.  Withholding acknowledgements for a period may allow more messages to be acknowledged in a single transmission, at the expense on the order of this delay in completion of the transaction.  The problem in the corner of the envelope of this timer is that in backchannel lossy networks, or at near saturation, of the forward channel, when channel transit time plus acknowledgementinterval begins to approach retransmission time, then wasted re-transmissions occur which yield almost the worst-case effect of further loading the forward channel.  This optimization (but not the timer) is useful for those systems where the receiver may be busy, but the channel is not, and may actually receive more than one message in the time it takes to persist and queue the acknowledgement.  In the case of a heavily loaded receiver, it would be most efficient in many circumstances to simply make a late decision in the preparation of the acknowledgement of exactly which messages are to be acknowledged.  Another point is that I suspect that messages will tend to be longer than acknowledgements unless there is other payload in the acknowledgement.  The channels would have to be highly asymmetrical for (in the case of a lightly loaded receiver) multiple messages to be received before it could get off an acknowledgement.  In any case, neither the sender nor the receiver know enough about the channel characteristics in the general case to establish a specific number for this.  Dynamic behavior is the best alternative.

Thanks

-bob

 


From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
Sent: Monday, October 24, 2005 3:42 PM
To: Marc Goodner; Bob Freund-Hitachi; 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]