Subject: RE: [PWE3] [Fwd: Proposed text for SAToP congestion section]

From: "Ron Cohen" <[email-masked]>
Date: Wed, 28 Dec 2005 17:57:45 +0200

Stewart,

My point was that there is a difference between changing the state machines of the SAToP protocol (current proposed text) and providing guidelines for operators to identify the problem and do corrective actions.

I could not understand from your reply whether you agree with me or not.

I would appreciate if you provide feedback whether the text I propose for this section is appropriate. It is copied here again for convenience.

8.  Congestion Control  
 
As explained in [PWE3-ARCH], the PSN carrying the PW may be subject to congestion, with congestion characteristics depending on PSN type, network architecture, configuration, and loading. During congestion the PSN may exhibit packet loss and PDV that will impact the timing and data integrity of the SAToP PW.
During intervals of acute congestion SAToP will not be able to maintain service.

SAToP PWs carry constant bit rate (CBR) services across the PSN and cannot behave in a TCP-friendly manner prescribed by [RFC2914]. SAToP PWs SHOULD be run over traffic-engineered PSNs providing bandwidth allocation and admission control mechanisms. IntServ-enabled domains providing the Guaranteed Service (GS) or DiffServ-enabled domains using EF (expedited forwarding) are examples of traffic-engineered PSNs. Such PSNs will minimize loss and delay while providing some degree of isolation of the SAToP PW's effects from neighboring streams.
 
If the PSN is not traffic engineered to accommodate for SAToP CBR service, congestion will occur and the SAToP service will not be able to deliver the service in required quality expected. The provider responsible for provisioning the SAToP service SHOULD monitor quality of SAToP service through its standard performance monitoring (e.g. errored second counter) and once it detects that the problem is due to congestion (e.g. through the packet loss counters) take the appropriate actions. These actions include re-traffic engineering its network or in extreme cases halt the service altogether.  

Thanks
Ron

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Wednesday, December 28, 2005 5:24 PM
To: Ron Cohen
Cc: pwe3
Subject: Re: [PWE3] [Fwd: Proposed text for SAToP congestion section]

Ron Cohen wrote:

>Hi,
>
>We should be very careful not to re-define the basic CES state machines while adding this section. CES is a CBR service. It is not a TCP friendly service and it is designed to provide emulation for TDM service. In particular, CES state machines are designed to quickly recover from network failures. It has criteria for decision whether the circuit should be declared as down and has specific performance monitoring parameters and alarms. The two excerpts below redefines basic behavior and state machines. 
>I believe the right approach is not to change the state machine of the protocol. CES should behave as a CBR service. If the network is not designed correctly to accommodate the CES CBR service the network administrator should detect that the CES service is not providing service as expected (e.g. though the errored-seconds counter), understand that this behavior is due to congestion (e.g. through the packet lost counters) and either solve the congestion problem (e.g. by traffic engineering the CES or TCP traffic) or close the service. 
>  
>
Ron

Surely this is what is happening. The PE - owned by the operator - detects that the congestion has reached a critical threshold (set by the operator) and the service is automatically shut down by the PE to prevent the network going into congestion collapse.

When this has happened the operator can re TE the network as required. 
However
to attempt to operate the TDM service when packet loss is so high that it is preventing the PW from delivering a TDM service, causes unnecessary congestion and risks the network going into congestion collapse.

Stewart

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3