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

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

Forwarding Alan's reply on his behalf.  (We'll see if the OASIS mail 
systems honour my Reply-to setting.)  The email reached the destination 
reliably (and is hereby acknowledged) but was lost by the sender :)

A question to Alan: What does "TPDU failures" mean?  Transport delivery 
uncertain?

thanx,
	doug

---

• From: Alan Weissberger <ajwdct@technologist.com>
• To: Doug.Bunting@Sun.COM
• Date: Wed, 30 Apr 2003 18:00:40 -0500

Doug

I think the WS-RM spec should have a note which says something about TCP retries on TPDU failures (NO ACK timer expire or request for retransmsission/backoff).  The note should  recommend setting WS-RM NO ACK Timer value >>> estimated worst case TCP recovery time.  Otherwise, duplicate re-transmissions will likely result, which could lead to network overload


alan

---- Original Message -----
From: Doug Bunting <Doug.Bunting@Sun.COM>
Date: Wed, 30 Apr 2003 15:50:13 -0700
To: wsrm@lists.oasis-open.org
Subject: Re: [wsrm] NEC Position on WS-RM flow/congestion control due to network 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
> 
> 



Alan Weissberger
2013 Acacia Ct
Santa Clara, CA 95050-3482
1 408 863 6042 voice
1 408 863 6099 fax

---