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

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 5 Jan 2006 14:28:08 +0200

Neil,
There is successful operational experience with SAToP,
CESoPSN and TDMoIP PWs running over IP networks.
(IMO this is one of the cases when Yaakov and I are in full agreement:-).

Hence whatever theory is built on the subject, I would expect it
to explain what exactly makes such a success possible, not just
why it should not exist.

Regards,
			Sasha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 05, 2006 2:00 PM
> To: Sasha Vainshtein
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [SPAM] - RE: [PWE3] Proposed text for SAToP 
> congestion section - Email found in subject
> 
> 
> 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
> 
> > -----Original Message-----
> > 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]
> > Subject: RE: [SPAM] - RE: [PWE3] Proposed text for SAToP 
> > congestion section - Email found in subject
> > 
> > 
> > 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
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Thursday, January 05, 2006 12:37 PM
> > > To: Sasha Vainshtein; [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: [SPAM] - RE: [PWE3] Proposed text for SAToP
> > > congestion section - Email found in subject
> > > 
> > > 
> > > 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 ...
> > > > 
> > > > 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.
> > >
> > [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 ...
> > > > 
> > > > 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 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). 
> > > > 
> > > > 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
> > > > 
> > > > 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
> > > > 
> > > 
> > 
> 

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