Subject: Re: [PWE3] [Fwd: Proposed text for SAToP congestionsection]

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 29 Dec 2005 14:15:12 +0200

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