Re: [wsrm] NEC Position on WS-RM flow/congestion control due tonetwork overload

[Doug Bunting <Doug.Bunting@Sun.COM>]

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