Subject: RE: Re: [PWE3] [Fwd: Proposed text for SAToP congestionsection] - Email found in subject

From: "Joe Merritt" <[email-masked]>
Date: Thu, 29 Dec 2005 14:57:54 -0500

[YJS] Joe - you are of course correct, but only thinking of your own
application. 
Once SAToP becomes an RFC it may and will be used by many people in many
wayss, including over the public Internet. It is one of the IETF's main
concerns to protect the Internet from congestion collapse, and thus all
new protocols must specify how they can coexist with existing protocols
without leading to collapse.
To the IESG (which has to OK SAToP's becoming an RFC) this is more
important than concerns regarding QoS of SAToP on private IP networks.

[JEM] I agree with your statement about IESG concern and focus however
IMHO I disagree with other discussion points and paragraphs 7 and 8 of
the draft-ietf-pwe3-satop. 

The concern seems to be around a user who attempts to provision SAToP PW
over the Internet and the perception that there are no means for
regulating the traffic if the Internet becomes congested. I am
suggesting that this may not be the case. There is an established OAM
methodology when using TDM that handles fault conditions. There are OAM
mechanisms on the TDM access connections that will be activated to stop
the traffic (certainly more brutal then TCP mechanisms).

If you start to lose packets from congestion in a PSN resulting from
inappropriate QoS and TE mechanisms then the buffers on the TDM IWF will
underflow causing a carrier alarm condition if the condition persists. A
Remote Defect Indication will then be sent to the far end indicating
loss of service. The TDM trunks will be brought out of service and
remain that way until the fault condition has been cleared for a
specified number of seconds. Is it possible to leverage these mechanisms
to meet the need of the IESG and require that the PEs support the TDM
OAM Methodology for cutting back the traffic during congested states
instead of shutting down the service?

For a SAToP PW to be successfully deployed then the PSN must have the
appropriate QoS and TE mechanisms established otherwise the CBR service
will not be viable.  Therefore, why does Section 7 and 8 use "should"
versus "must"? 

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Thursday, December 29, 2005 7:15 AM
To: Joe Merritt; Stewart Bryant
Cc: pwe3
Subject: Re: [PWE3] [Fwd: Proposed text for SAToP congestionsection] -
Email found in subject

A service provider who plans to use SAToP PW over a PSN (UDP/IP, MPLS,
or L2TP) to deliver DS1/E1 transport services, will ensure that the
underlying PSN is well behaved (e.g. Bell South architecture for
Ethernet services) because the service operates under a tariff. The
service provider will integrate the SAToP into their management systems
(provisioning, fault management, etc.) and operations staff. The service
must be consistent throughout otherwise it will not be adopted or
deployed.

[YJS] Joe - you are of course correct, but only thinking of your own
application. 
Once SAToP becomes an RFC it may and will be used by many people in many
wayss, including over the public Internet. It is one of the IETF's main
concerns to protect the Internet from congestion collapse, and thus all
new protocols must specify how they can coexist with existing protocols
without leading to collapse.
To the IESG (which has to OK SAToP's becoming an RFC) this is more
important than concerns regarding QoS of SAToP on private IP networks.

DS1/E1 transport services do not have the concept of congestion but
rather errors, defects, and faults whenever there are problems in the
network (failing repeaters, cable problems, etc.). OAM methodology
specifies that these events will trigger alarms and the associated
corrective actions.

[YJS] The fact that TDM does not experience congestion is precisely why
the SAToP draft has to deal with it. Of course, when viewing a SAToP
island in the middle of TDM domains, you are perfectly right in stating
that te emulated domain has to be treated just as a true TDM domain
would be - including counting errored seconds and raising alarms.

SAToP PW (CBR) service should have the highest priority in a packet
network. The underlying core PSN should never be allowed to
over-provision CBR flows and when experiencing congestion all UBR and
VBR flows should be discarded as required to achieve an uncongested
state. 

[YJS] Once again, you are considering only the (easy) well engineered
case.

My concern is that the SAToP PW should not be adversely affected by
congestion in the PSN. The architecture of the PSN should be able to
support the requirements associated with SAToP PW otherwise it should
not be allowed to be provisioned. 

Terminating the SAToP PW will not prevent a poorly designed PSN from
collapsing; it will only delay the event. 

[YJS] This is the crux of the matter. True - an emulated TDM link taken
down will adverse effect many users, and thus may be "high priority" to
the provider of the emulated TDM service. However, the operator
prividing the lower layer transport over which this service runs might
think otherwise.

[YJS] In any case, stating that terminating SAToP will not prevent
collapse is similar to stating that using TCP without cutting-back rate
will not prevent collapse. For a single service that is a small fraction
of the available BW you are right; but for a service to become an RFC we
have to consider the worst case where it is a major fraction of the BW.

Y(J)S

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

---

From: Scott W Brim <[email-masked]>
Date: Thu, 29 Dec 2005 15:34:14 -0500

On 12/29/2005 14:57 PM, Joe Merritt allegedly wrote:
> underflow causing a carrier alarm condition if the condition persists. 

Joe, the issue is flows that don't notice the problem and just keep
throwing packets at the PSN.