Subject: RE: [SPAM] - RE: [PWE3] Proposed text for SAToP congestion sectio n - Email found in subject

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 5 Jan 2006 11:05:34 +0200

Joe,
To the best of my understanding, tying up the native TDM OAM
with the SAToP congestion avoidance techniques is impossible.

Let's consider the following (intentionally simplified) example:

1. One of the directions of an E1 SAToP PW experiences an
   "acute congestion" to the extent that multiple
   consecutive SAToP packets are lost.

2. Based on this, the receiving SAToP PW end point shall
   enter "loss of packet" state and start sening "all ones"
   pattern (i.e., E1 AIS) towards its local TDM CE

3. The TDM CE shall respond with sending E1 RDI towards its
   local PE containing the SAToP PW end point.

4. However, the SAToP PW end point, being structure-agnostic,
   shall NOT recognize E1 RDI condition (since this condition,
   as opposed to E1 AIS, requires awareness of the E1 framing
   structure) and, consequently, shall NOT be able to handle it
   in any way.

5. On the other hand, SAToP shall, upon entering its packet loss state,
   start transmitting back packets with the R flag set in its CW.
   This will be nored by the peer PW end point and can be, potentially,
   acted upon.

The main simplification taken in this example is the assumption of
100% packet loss for some period. 

If we assume, say, 50% packet loss, SAToP can, by using "intelligent" 
replacement of lost packets, generate an E1 flow with lots of CRC-4 
errors but without AIS or LOF being perceived by the local TDM CE. 

Please note also that SAToP cannot, under any circumstances, result in
the local TDM CE perceiving LOS on its PE-facing TDM interface. This
is because SAToP, by design, does not make ay assumptions on the
way in which the TDM signal is provided by the PE. E.g., SAToP can
operate (and is deployed) in the situations when an E1 bit-stream
is delivered embedded in channelized STM-1 (or a DS1 bit-stream
is delivered embedded in channelzed DS3). 

Hopefully these notes clarify the situation.

Regards,
				Sasha

> -----Original Message-----
> From: Joe Merritt [mailto:[email-masked]]
> Sent: Wednesday, January 04, 2006 7:27 PM
> To: Scott Brim (sbrim)
> Cc: [email-masked]
> Subject: RE: [SPAM] - RE: [PWE3] Proposed text for SAToP 
> congestion section - Email found in subject
> 
> 
>  Scott,
> 
> In the discussion about congestion around SAToP, I have not seen any
> discussion around tying in the OAM of TDM access connections with the
> PSN pseudo wires. When congestion develops and packets start being
> dropped on a SAToP PW the TDM access connections will 
> experience errors.
> If the errors persist then a defect (e.g. severely errored seconds) is
> triggered. A persistent defect triggers a fault condition (carrier
> alarm). At that point the trunk is normally out of service until the
> fault conditioned is cleared.
> 
> Would it seem reasonable to use these mechanisms (AIS, LOS, 
> RDI) in the
> congestion management of the PSN SAToP pseudo wires? These mechanisms
> are currently in place when Murphy is at work in the TDM network.
> 
> Regards,
> Joe
> 
> -----Original Message-----
> From: Scott Brim (sbrim) [mailto:[email-masked]] 
> Sent: Wednesday, December 28, 2005 5:45 PM
> To: [email-masked]; Joe Merritt
> Cc: [email-masked]
> Subject: [SPAM] - RE: [PWE3] Proposed text for SAToP 
> congestion section
> - Email found in subject
> 
> 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
> 

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

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 5 Jan 2006 13:18:20 +0200

Neil,
Thank you for a prompt response.
Please see some brief clarifications inline below (marked [Sasha]).
I have snipped the parts of the text where we seem to be in agreement.

Regards,
			Sasha

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 05, 2006 12:37 PM
> To: Sasha Vainshtein; [email-masked]
> Cc: [email-masked]; [email-masked]
> Hi Sasha....tend to agree with your conclusion but for different
> reasons.....please see remarks inserted in-line below.
... snipped ...
> 
> Sasha wrote 05 January 2006 09:06
> > 
> > Joe,
... snipped ...
> NH=> There is key step missing here....against what entry 
> criteria (inc > measurement time) is a defect declared?.....
> there is a similar exit criteria requirement.
>
[Sasha] The current spec says that the number of consecutive lost
packets that defines entry to the "Packet Loss" state of the
SAToP receiver (which, in the case of a SAToP PW, is, of course, 
equivalent to time) is configurable. The same goes for exiting the
the "Packet Loss" state (i.e., the number of conscutive packets received).
... snipped ...
> >    This will be noted by the peer PW end point and can be, 
> > potentially,
> >    acted upon.
> NH=> It is technically wrong for the server layer BDI to 
> generate a BDI in its client(s).  
>
[Sasha] Just to confirm that SAToP does NOT do that, i.e. 
it does not translate PW BDI to TDM BDI. 
... snipped ...
>
> > 
> > The main simplification taken in this example is the 
> > assumption of 100% packet loss for some period.
> NH=> 'Some' period?  One really needs an agreed set of defect 
> entry/exit criteria. 
> > 
> > If we assume, say, 50% packet loss, SAToP can, by using 
> > "intelligent" replacement of lost packets, generate an E1 flow 
> > with lots of CRC-4 errors but without AIS or LOF being perceived 
> > by the local TDM CE. 
> NH=> One should not be playing about with the client layer signal like
> this.  I do hope you are not serious.
>
[Sasha] The question here is, what can a SAToP receiving end point do when
it misses a packet with the client signal? It still has to transmit
some bits towards its local CE, and, since it did not receive these
bits, it must generate them. The default action is generation of
"all ones". But this can result in premature AIS detection by the
CE, especially in the case of an E1 AC where 0.25 ms of all ones
would be identified as an AIS defect. (High sensitivity of E1 to
short bursts of "all ones" has been defined in ITU-T G.775 long time
before SAToP has been born.:-)
Hence the spec allows more intelligent substitution of lost bits 
- but only for limited time. Once this time expires without any 
packets being received, SAToP shall (by entering its packet loss 
state) generate TDM AIS towards its local CE.
>
> > 
> > Please note also that SAToP cannot, under any circumstances, 
> > result in the local TDM CE perceiving LOS on its PE-facing 
> > TDM interface. This is because SAToP, by design, does not 
> > make ay assumptions on the way in which the TDM signal is 
> > provided by the PE. E.g., SAToP can operate (and is deployed) 
> > in the situations when an E1 bit-stream is delivered embedded 
> > in channelized STM-1 (or a DS1 bit-stream is delivered 
> > embedded in channelzed DS3). 
> > 
> NH=> Well, not really.  There is still the major O/S point I mentioned
> at the outset wrt the differenmce between 'urgency' and
> 'importance'....and I see no fix for this with a cl-ps server layer
> because one needs a trail IMO to properly decouple these semantics. 
> 
> regards, Neil
> > 
> > Regards,
> > 				Sasha
> > 
> > 
> > 
> > 
> > > dropped on a SAToP PW the TDM access connections will experience 
> > > errors. If the errors persist then a defect (e.g. 
> severely errored 
> > > seconds) is triggered. A persistent defect triggers a fault 
> > condition 
> > > (carrier alarm). At that point the trunk is normally out 
> of service 
> > > until the fault conditioned is cleared.
> > > 
> > > 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