[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] NEC Position on WS-RM flow/congestion control due tonetwork overload
A quick question for all on this conclusion. (I also agree but that isn't the point of this email :) I'm thinking TCP has to address requirements that may not be as much an issue for our specification. We in the WS-RM TC are dealing with reliability under a message-passing paradigm while TCP development was focused on a connection-oriented architecture. We don't have to worry as much about the downsides of breaking a particular connection. That is, breaking a WS-RM "connection" is a perfectly reasonable server response to overload. However, the mechanisms proposed for reliability (the overall acknowledgment paradigm) in this TC have the *effect* of reducing both network and server load. WS-RM message senders should not immediately attempt to restore broken connections, giving the server a chance to recover. This is especially true when retries frequency rates are set reasonably and / or when backoff algorithms are used. Should our final specification point out the effect retry timing and backoff algorithms have on server and network overload? Just a non-normative note or an explicit description of applicable backoff algorithms and a RECOMMENDATION (in 2119 terms) for their use? thanx, doug On 30-04-2003 02:14, Paolo Romano wrote: > I agree with Alan's CONCLUSION as well. > > Paolo > >>Hi Alan, >> >>I agree with the CONCLUSION. >> >>br, >>Magdolna >> >>-----Original Message----- >>From: ext Alan Weissberger [mailto:ajwdct@technologist.com] >>Sent: April 29,2003 21:12 >>To: wsrm@lists.oasis-open.org >>Subject: [wsrm] NEC Position on WS-RM flow/congestion control due to >>network overload >> >> >>All ... >>3. Conclusion: As WS-RM entities can NOT DISTINGUISH BETWEEN TRANSPORT >>CONNECTION FAILURE(s) and NETWORK OVERLOAD CONDITION(s), it is NOT >>practicable to consider WS-RM FLOW/CONGESTION CONTROL. >> >>-->ONLY IF A CONGESTION INDICATION/CONGESTION EXPERIENCED INDICATOR IS >>AVAILABLE (set by a lower layer and passed up the protocol stack to >>WS-RM entity) SHOULD WE EVEN CONSIDER THIS FUNCTION IN WS-RM. >> >>Thank you for your attention >> >>alan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]