Congestion framework for Pseudowires draft-rosen-pwe3-congestion-04.txt Bruce Davie (with Eric Rosen, Stewart Bryant & Luca Martini)

Introduction This is a framework, not a solution draft Tried to examine the issues and list a range of solutions –Tradeoffs to be made in most cases

What is a pseudowire Tunnels (MPLS, GRE, IPSEC, L2TPv3, etc.) Emulated VCs inside tunnels (many-to-one) Attachment VCs (e.g. FR) mapped to emulated VCs PWs are bidirectional (but may only have one-way traffic) dlci 202 Attachment VC Lvc Emulated VC Tunnel Lvc Emulated VC dlci 101 Attachment VC

Why PWs need Congestion Control PWs can carry any sort of traffic, which may not be congestion controlled by the end points Continued health of the Internet requires congestion control of most traffic

Why PWs might not need Congestion Control All the traffic is IP –If UDP, reduce to a previously unsolved problem –If TCP, there’s no need, and prior experience with poor control loop interactions (ATM-ABR) PW service only offered on well-engineered nets, not the Internet at large PW is a premium service that should be able to trample on less important stuff –Never enough PW traffic to congest the net on its own None of these arguments really stand up to scrutiny

Primary Cases of Concern TDM PWs Packet PWs carrying non-congestion- controlled traffic –e.g. Ethernet PW carrying MPEG-2 Deployed over widely shared infrastructure –e.g. the Internet

Design constraints Large number of PWs per edge device –Maintaining TCP-like state per PW considered too costly Hardware data plane implementation typical Existing encapsulations not designed for congestion control Concern about bandwidth efficiency No ACKs in general

Design Choices - Summary How to detect/measure loss rate/congestion? –SEQ numbers or OAM-based or ECN How to feed loss rate/congestion back to sender? –Data, control, or management plane What to do on congestion? –Shape, police, shut-down What to do as congestion abates? Granularity of control –Per-tunnel, per-PW

Detecting Congestion Using sequence numbers has drawbacks –SEQ is optional; using it (today) means misordering becomes loss –False congestion signals if misordering occurs Control/management plane approach –Periodically transmit a count of packets sent in forward direction, count of packets received in reverse direction –Counters in HW, control messages in SW, likely to cause some inaccuracy (as will misordering) –Likely to be less error-prone that SEQ approach –How often - about once per RTT seems needed ECN or PCN –Lack of deployment a concern

Feedback to ingress No reverse data for many PWs Could use a PW control message or an OAM message

TCP Friendly Rate Control RFC3448 –Calculates rate that a TCP connection would get if same loss rate and RTT applied Note: need RTT measurement between PEs Smoother than the standard TCP “sawtooth” Could police/shape the PW or tunnel to that rate Hopefully a no-op Could use local policy to prefer some PWs in a tunnel Could be achieved by selective shutdown of one or more PWs in a tunnel Somewhat tolerant to inaccurate loss measurement Note: already included in FiberChannel PWE spec

Summary of issues Exactly what is the right way to measure congestion & thus set rate? How often to sample loss –Once per RTT seems about right - is less often OK? How to enforce rate? –Shutting off PWs is simple but blunt –Shaping PWs risks TCP interaction –Police-by-dropping considered harmful to TCP Should this be mandatory for all PWs? –Mandatory to implement vs. to enable