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

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

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. 
 
The problematic excerpts:

                     "Because PWs are inherently birectional, the detecting PE can terminate the SAToP 
                      service without explicitly communicating with the remote PE. The PE initiating 
                      termination simply ceases transmission of SAToP packets. The other PE, even if previously 
                      unaware of a problem, will of necessity detect that packets are not arriving and 
                      MUST similarly cease packet transmission."
                      "If the PW has been set up using the PWE control protocol, then procedures specified in 
                      [PWE3-CONTROL] for label Withdrawal MAY be used as well. The PW may be restarted 
                      by manual intervention, or by automatic means after an appropriate waiting time."

                      "In the presence of services that reduce transmission rate, SAToP PWs will thus 
                       consume more than their fair share (although being CBR, the percentage of total 
                       bandwidth they consume remains constant) and SHOULD be halted."

Below please find a draft text for this section:

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.  

Happy holidays
Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Tuesday, December 27, 2005 12:14 PM
To: pwe3
Subject: [PWE3] [Fwd: Proposed text for SAToP congestion section]

Following discussion with the transport ADs, we propose that text of the following form be added to the TDM drafts.

I think that we need to add similar text to our other drafts to cover the case where they are used to carry non-TCP friendly streams.

The obvious cases is where this is needed is ATM cell mode.

- Stewart

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 accute congestion SAToP will not be able to maintain service.
In addition, since SAToP PWs carry constant bit rate (CBR) services across the PSN, they cannot behave in a TCP-friendly manner prescribed by [RFC2914].
In the presence of services that reduce transmission rate, SAToP PWs will thus consume more than their fair share (although being CBR, the percentage of total bandwidth they consume remains constant) and SHOULD be halted.
 
Whenever possible, 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.
 
The PEs SHOULD monitor for congestion (by using explicit congestion notification, VCCV, or by measuring packet loss) in order to ensure that the SAToP service may be maintained. Note that SAToP packet loss rate may always be measured unintrusively since the expected packet arrival rate is known and fixed.
When significant congestion is detected the SAToP service SHOULD be terminated. Because PWs are inherently birectional, the detecting PE can terminate the SAToP service without explicitly communicating with the remote PE. The PE initiating termination simply ceases transmission of SAToP packets. The other PE, even if previously unaware of a problem, will of necessity detect that packets are not arriving and MUST similarly cease packet transmission.
If the PW has been set up using the PWE control protocol, then procedures specified in [PWE3-CONTROL] for label Withdrawal MAY be used as well. The PW may be restarted by manual intervention, or by automatic means after an appropriate waiting time.

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

--
This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

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

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 28 Dec 2005 15:24:24 +0000

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