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

From: Stewart Bryant <[email-masked]>
Date: Tue, 03 Jan 2006 18:06:29 +0000

Ron Cohen wrote:

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

Your text does not completely respond to the discuss

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=43563

Please write substantive congestion control considerations.  RFC 3985, 
the PW architecture,
included an agreed on congestion avoidance procdure for PWs that can't
change their rates (inelastic), such as CBR.  This was to shut off for some
period once they measure a certain level of loss, IFF they are in a 
best-effort PSN.
This is found in Section 6.5, paragraph three.  I think the Congestion 
Control Considerations
needs to say something like:  a CBR PW  SHOULD be run over 
traffic-engineered systems
providing it AF (minimal loss, low impact on other streams) or better, 
to avoid risk
of congestion on the PSN and the service, or it SHOULD perform the loss 
monitoring
described in RFC 3985, section 6.5 and when the loss is higher than a 
threshold,
shut itself down for some waiting period determined to avoid congestion 
pulses.

You cover the case where the operator is fully in control of the 
situation, but not
the case where the PW is not fully monitored by the operator, perhaps 
because
they are unaware of its deployment.

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

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