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

From: "Scott Brim \(sbrim\)" <[email-masked]>
Date: Wed, 28 Dec 2005 17:45:18 -0500

On Wednesday, December 28, 2005 17:20 PM, [email-masked]
allegedly wrote: 
> Joe,
> 
>> 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.
> 
> I agree, that's how it's supposed to work.  Then Murphy strikes (e.g.,
> riding a backhoe ...) and suddenly the network lacks sufficient
> capacity for the CBR flows.  Now what?

That's what I had in mind when I suggested that you put the traffic
engineering text at the top, followed by the text on "in case of
resource shortage".  In most cases TDM traffic is given GS/EF treatment
which both protects and limits its resources -- congestion an issue if
and only if there are failures.  However, in case there are failures, or
in case the network does not give the TDM traffic that kind of
protection/limits, we recommend killing the service.

> I'm not sure whether "guidelines" is enough.  The buck has to stop
> somewhere, as allowing the CBR traffic to blast onwards as if the
> backhoe event hadn't happened is a very bad idea (e.g., if
> the operator isn't paying attention).

Agreed.

> OTOH, TCP may need as much as an end-to-end RTT on the (now-congested)
> network to figure out that it has a problem (or possibly even longer
> in some situations).  If the operator's OAM gear can react inside of
> that time period (I suspect such a reaction has to be automated), the
> result can probably be characterized as able to coexist with TCP in
> some fashion.  Perhaps Stuart's text could use some discussion of
> (automated) operator intervention as the preferred means of dealing
> with a mess like this with service termination described only as a
> last resort backstop? 

It's a TDM transport service, so you can't back off part-way.  It's
either on or off.

See you ... Scott

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