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

1
Congestion framework for Pseudowiresdraft-rosen-p
we3-congestion-04.txt

• Bruce Davie
• bsd_at_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, theres 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