Congestion framework for Pseudowires draft-rosen-pwe3-congestion-04.txt

1. Congestion framework for Pseudowiresdraft-rosen-pwe3-congestion-04.txt Bruce Davie bsd@cisco.com (with Eric Rosen, Stewart Bryant & Luca Martini)

2. 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

3. 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 • IESG says so

4. 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

5. 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

6. 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 • Granularity of control • Per-tunnel, per-PW

7. 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

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

9. 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

10. 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