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

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 27 Dec 2005 17:10:04 +0200

Stewart, Andy and all,
I agree with Andy that the original SAToP text cannot be used
"as is" in the ATM encapsulation draft. The main reason for that
is SAToP PW end points can measure their own packet loss rate
(as the expected packet arrival rate is known and fixed), while
ATM PW end points cannot perform any such measurement and hence 
cannot reliably detect congestion. 

Generic methods for detecting PW congestion have been discussed
in draft-rosen-pwe3-congestion-02.txt (now expired), but this
work seems to be stalled.

Regards,
			Sasha

> -----Original Message-----
> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Tuesday, December 27, 2005 4:55 PM
> To: Stewart Bryant
> Cc: pwe3
> Subject: Re: [PWE3] [Fwd: Proposed text for SAToP congestion section]
> 
> 
> Stewart,
> 
> We would have to amend this somewhat for ATM cell mode.  For example, 
> we would have to change parts of the text below to read something like
> 
> During intervals of acute congestion, some ATM PWs may not be able to 
> maintain service. Those ATM PWs that carry constant bit rate (CBR) 
> and VBR-rt (Variable Bit Rate-real time) services across the PSN will 
> most probably not behave in a TCP-friendly manner prescribed by 
> [RFC2914]. In the presence of services that reduce transmission rate, 
> ATM PWs carrying CBR and VBR-rt traffic may thus consume more than 
> their fair share and SHOULD be halted.  ATM PWs carrying UBR 
> (Unspecified Bit Rate) traffic are equivalent to best-effort IP 
> service and need not be halted during congestion, and MAY have cells 
> delayed or dropped by the ingress PE if necessary.  ATM PWs carrying 
> VBR-nrt (Variable Bit Rate-non real time) VCs may or may not behave 
> in a TCP-friendly manner, depending on the end user application, but 
> are most likely safe to continue operating, since the end-user 
> application is expected to be delay-insensitive and may also be 
> somewhat loss-insensitive.
> 
> Cheers,
> Andy
> 
> -------------
> 
> At 12/27/2005 10:13 +0000, Stewart Bryant wrote:
> >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
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

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