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

From: "Gray, Eric" <[email-masked]>
Date: Tue, 3 Jan 2006 17:46:45 -0500

Stewart,

	One thing to remember to add to the "institutional memory" is
that more has changed than just the acquisition of those memories.  
Equipment vendors and network operators have also learned from the
experience.  I believe it is fair to say that network equipment with 
severely limited ability to segregate (virtual) output queues is 
largely a thing of the past.  That being the case, it is also likely 
today's equipment can better handle yesterday's congestion problems.

	In particular, where equipment is specifically designed to 
support traffic class segregation, it is interesting that we want
to encourage behavior that ignores that capability generally.

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Stewart Bryant
--> Sent: Tuesday, January 03, 2006 1:52 PM
--> To: Yaakov Stein
--> Cc: pwe3
--> Subject: Re: [PWE3] [Fwd: Proposed text for SAToP 
--> congestion section]
--> 
--> Yaakov summarizes the situation well.
--> 
--> Although the PWE3 WG has been reluctant to address the
--> issue of congestion, the issue of congestion has been a
--> concern for the Transport ADs since the inception of the
--> PWE3 WG. Indeed that is why we were originally placed in
--> the Transport Area. As I understand it, there is
--> institutional memory of Internet failures due to
--> inadequate congestion avoidance by transport protocols,
--> so this is a sensitive issue in the transport area.
--> 
--> Whilst TE can mitigate the problem a number of issues
--> remain:
--> 
--> 1) We cannot constrain how and where TDM PW technology
--> is deployed. This is particularly the case where the
--> PW is encapsulated in IP (via UDP, L2TP or MPLS/GRE).
--> In particular the technology may not be SP deployed.
--> 
--> 2) Even when TE is used there is the issue of one or more
--> unexpected events leading to unanticipated severe
--> congestion.
--> 
--> Where the SP provides the TDM service, shutting the
--> TDM service down would be a serious issue. However
--> there is a point at which the network needs to save
--> itself, since the network itself is maintained by VBR
--> traffic (routing messages and operational control
--> messages are VBR).
--> 
--> The way that the proposed text is written there is
--> a threshold of packet loss (set by the owner of
--> the PE) at which the TDM service is to some degree
--> terminated (either completely or circuit by circuit).
--> By incorporating this in the PE, this action gets
--> invoked automatically.
--> 
--> To be of any use the action has to be automatically
--> applied at the PE (because an instruction to the PE
--> may be competing with the PE CBR traffic and hence
--> being discarded).
--> 
--> The threshold at which TDM traffic is not specified
--> in the text. This means that those operators that
--> do no believe that this is a problem can simply set
--> it so high that it will never be invoked. Whilst
--> those that are concerned that there might be a need
--> to shed CBR load in the event of a failure can take
--> a judgment call on when to start turning off the
--> TDM PWs to allow VBR traffic to resume.
--> 
--> - Stewart
--> 
--> 
--> 
--> Yaakov Stein wrote:
--> 
--> >Ron
--> >
--> >I looked over the changes you propose, 
--> >and really don't see what problems they solve.
--> >
--> >Let me first reiterate why we rewrote this section.
--> >
--> >SAToP came up on the IESG telechat.
--> >There was a DISCUSS from Allison asking for a more substantive
--> >congestion section. More specifically she asked for
--> >1) a congestion avoidance procdure for CBR PWs,
--> >   specifically to shut off for some period once a certain 
--> level of loss
--> >   was encountered (as measured using RFC 3985, section 6.5)
--> >2) differentiationg between best-effort and TE PSNs, with
--> >3) a "SHOULD" for running over traffic-engineered systems 
--> >   to avoid risk of congestion on the PSN, and
--> >4) loss monitoring for non-TE systems. 
--> >Without this content Allison was against SAToP going forward.
--> >
--> >After lengthy discussion between myself and Sasha,
--> >with participation of Stewart and Mark, 
--> >we rewrote the section to both answer the points raised
--> >by Allison, while emphasizing issues we believed were important.
--> >
--> >I forwarded this text to Allison who replied 
--> >"I like your proposed text a lot.  It really does a good job."
--> >
--> >Stewart then forwarded the text to the list, in order
--> >to save time when submitting the next drafts (ATM, etc).
--> >
--> >Now you are proposing changes that bring us back much
--> >closer to the text that was rejected in the original
--> >DISCUSS, namely avoiding mention of best-effort PSNs,
--> >and trying to avoid halting the service when it may
--> >endanger other services in such PSNs.
--> >
--> >Sorry, but I believe we need to resubmit with the
--> >text we proposed and for which we received the OK.
--> >
--> >Y(J)S
--> >
--> >_______________________________________________
--> >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