OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


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


Doug

TPDU= Tranport Protocol Data Unit (think of it as a Transport layer pkt)
TPDU failure simply means the given pkt was not properly ACK'd, e.g. the TPDU was lost, the ACK was lost, or the TPDU arrived out of sequence and must be retransmitted

alan
----- Original Message -----
From: Doug Bunting <Doug.Bunting@Sun.COM>
Date: Wed, 30 Apr 2003 16:21:43 -0700
To: wsrm@lists.oasis-open.org
Subject: [Fwd: Re: [wsrm] NEC Position on WS-RM flow/congestion control due to network overload]

> 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

Content-Type: message/rfc822; name="Re: [wsrm] NEC Position on WS-RM flow/congestion control due to network" overload"
From: Alan Weissberger <ajwdct@technologist.com>
Date: Wed, 30 Apr 2003 18:00:40 -0500
To: Doug.Bunting@Sun.COM
Subject: Re: [wsrm] NEC Position on WS-RM flow/congestion control due to network overload
Message-Id: <20030430230040.46441.qmail@iname.com>


>
> 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
> 



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



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