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

From: "Joe Merritt" <[email-masked]>
Date: Wed, 4 Jan 2006 12:27:04 -0500

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

---

From: [email-masked]
Date: Thu, 5 Jan 2006 10:37:03 -0000

Hi Sasha....tend to agree with your conclusion but for different
reasons.....please see remarks inserted in-line below.

However, the more general point is this:

There is no relationship between (i) the up-state QoS (urgency) and (ii)
the down-state survivability (importance) of an application (or its
respective UDP, TCP, RTP adaptation function)......any
application/application-adaptation can assume any importance.

This applies to applications in both a public and private service
context.....though it's arguably more important to get the latter right,
and it's arguably more correct to say that PWs are very much private
service-like in nature.  Why?  Because multiple different applications
can (as clients) use a private service server layer trail and these can
change epoch by epoch in both type and importance/urgency
requirements.....in other words an operator cannot make a judgement call
on an individual traffic unit in a private services context, and to be
practically tractable one must apply the importance semantic to the
parent (server) trail.  Bit of a problem if your server layer does not
have the required trail attributes, eg cl-ps networks don't have trails
by definition.....and a mp2p construct in MPLS also does not have trail
attributes either, but that is a different issue.

Further, a real failure event is quite different to a transient
congestion loss event.....but over a short evaluation period they will
look alike.  So some thought needs to exercised as when defects are
declared (and exited) and what consequent actions are taken and
where.....which leads into what you are discussing below to some extent.

Now please see below.....

Sasha wrote 05 January 2006 09:06
> 
> Joe,
> To the best of my understanding, tying up the native TDM OAM 
> with the SAToP congestion avoidance techniques is impossible.
NH=> I agree.
> 
> 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
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.
> 
> 3. The TDM CE shall respond with sending E1 RDI towards its
>    local PE containing the SAToP PW end point.
NH=> Looks right.....only a true trail termination point should send a
BDI....and this MUST only be generated as a consequence of (in this
example case) the E1 trail declaring its own loss of framing in the
*other* direction.  A 'burst' of FDI/AIS less than this period should
*not* cause a defect state (and thus BDI) to be returned.
> 
> 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.
NH=> Not sure one should assume this is 'bad'.....this is precisely what
SHOULD be the case, ie a server layer should always transparently convey
its client.  Of course some of the PW encaps break these rules by
snooping the client and removing some of its characteristic
information.....the structure aware stuff is like this, so is the FCS
stripping of an ethernet client.  In general these are bad behaviours.
> 
> 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.
NH=> It is technically wrong for the server layer BDI to generate a BDI
in its client(s).  In the general case, the server layer is but 1
link-connection of the client layer trail, so several client layer
trails could be carried on THIS link-connection but their source trail
termination points could be in quite different locations.....and the
server layer will not, and should not, know about these.  Hence the
point above that BDI should only be generated at the appropriate
place....here the true E1 trail term point after it sees its own loss of
framing defect occur.
> 
> 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.
> 
> 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.
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
> 				Sasha
> > 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,
> > 
> > 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.
> > 
> > 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

---

From: [email-masked]
Date: Thu, 5 Jan 2006 11:59:38 -0000

Thanks Sasha.....perhaps we are overlooking the rather obvious
conclusion here, ie we should not, as a general case, be carrying a
co-cs client like E1 over a cl-ps server layer network?  I can provide
some rather heavyweigh and detailed arguments to support this based on
work we have been doing on Unified Modelling where we can show, from
information Theory considerations,:
-	how the 3 modes arise.....and its not by chance but there are
some deeper truths here about the nature of end-point and
resource-partition labelling;
-	what the attributes of a trail are and why it's such an
important network object;
-	why all traffic can be reduced to either message/file/stream and
it's thus no coincidence that UDP/TCP/RTP cover all cases (and why only
AAL5 and AAL1 adaptation functions in ATM were relatively successful)
and thus we don't need lots of traffic/QoS classes......but this does
imply their interfacing to a single mode network is going to yield
optimal solutions over all public/private service cases....in fact mode
selection largely negates the need to worry about QoS.  {This issue is
also closely related to an ability to fairly and consistently price
services over all load points).

IMO we need a different mindset/approach to the target Next Gen network
arch where the 3 network modes work in concert to provide a full suite
of public and private services.  Think we are still some way off seeing
the need for this however......the financial pain needs to increase even
more yet, but it's coming.  So I think we'll stumble around the problems
(like this one) for some time yet.

regards, Neil

> From: Sasha Vainshtein [mailto:[email-masked]] 
> Sent: 05 January 2006 11:18
> To: Harrison,N,Neil,JRD1 R
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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]
> ... snipped ...
> ... 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 ...
> >
> > > 
> > 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. 
> [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.
> >
> > >