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

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Dec 2005 10:13:33 +0000

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Dec 2005 09:54:36 -0500

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:
>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
>During intervals of accute congestion SAToP will not be able to 
>maintain service.
>simply ceases transmission of SAToP packets. The other PE, even if previously

---

From: Scott W Brim <[email-masked]>
Date: Tue, 27 Dec 2005 10:25:21 -0500

Hi.  I would delete some, edit some, and move a paragraph from 60% of
the way down up to the top.

> 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

s/will/might/ ... since it is the goal that it *not* impact the PW.

> the timing and data integrity of the SAToP PW.  During intervals of
> accute congestion SAToP will not be able to maintain service.

If the PW is engineered with sufficient resources, then congestion
alone will not be a problem, since other traffic could be dropped as
needed.  Failures might be a problem but not congestion itself.
Perhaps you could say "during intervals of acute resource shortage".

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

I don't understand combining "fair share" and CBR.  When you engineer
a PW for CBR, it removes it from consideration of "fairness" of
distribution of resources.  I would delete this paragraph ...

> and SHOULD be halted.

... except for this.  During intervals of acute resource shortage,
when the PW service requirements cannot be met, the service 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.

I would move this paragraph up to the top.  Considerations of all of
the other issues depend on this.

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

Again, congestion itself is not the problem.  "Resource shortage" as a
general term?

The rest is okay.

Thanks ... Scott

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

---

From: Eric W Gray <[email-masked]>
Date: Wed, 28 Dec 2005 08:51:59 -0500

Andy,

    This text - as well as the original text - seems to forget the 
commercial aspects of
various types of CBR and real-time services.

    As Scott (Brim) points out in separate E-Mail, these services are 
typically not in a
"fair queuing" mode relative to other types of services and may still be 
functional (and
earning revenue / avoiding revenue loss) under all but the worst 
congestion conditions.

    However, adding further to Scott's comments, it is innappropriate 
for a specification
such as we discuss here to dictate (or strongly urge) a specific 
behavior that is more
"business application affecting" than implementation, or necessarily 
"network operation
affecting" - except to the extent that Scott suggests qualifying it 
(i.e. - if it won't satisfy
the application requirement anymore, then it is appropriate to "urge" 
termination of the
service).  And, I am fairly certain that applications that require 
strict CBR or real time
services will themselves effectively terminate a service if it is no 
longer meeting the needs
of the application - thus making this not a network operations decision.

--
Eric

Andrew G. Malis wrote:

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 28 Dec 2005 13:39:17 -0500

Eric,

This is the same general direction that Ron and Joe are going in for 
SAToP.  I was attempting to adapt the originally offered text, but I 
do agree with you, Scott, Ron and Joe on its deficiencies. let's wait 
for the TDM discussion to converge on final text and then adapt that to ATM.

Cheers,
Andy

At 12/28/2005 08:51 -0500, Eric W Gray wrote:
>    As Scott (Brim) points out in separate E-Mail, these services 
> are typically not in a
>"fair queuing" mode relative to other types of services and may 
>still be functional (and
>    However, adding further to Scott's comments, it is 
> innappropriate for a specification
>the application requirement anymore, then it is appropriate to 
>"urge" termination of the
>>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 
>>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
>>
>>-------------
>>
>>>As explained in [PWE3-ARCH], the PSN carrying the PW may be 
>>>subject to congestion,
>>>In addition, since SAToP PWs carry constant bit rate (CBR) 
>>>services across the PSN,
>>>(although being CBR, the percentage of total bandwidth they 
>>>The PEs SHOULD monitor for congestion (by using explicit 
>>>congestion notification,