Congestion Issues

1
Congestion Issues

• Stewart Bryant stbryant_at_cisco.com

2
Creation of PWE3 WG

• When the PWE3 WG was formed it was put in the
  Transport Directorate because of concerns that
  the PWs would congest the Internet.
• Arguments at the time that PWs would only run
  over traffic engineered networks we were
  countered by noting that in all instances where a
  protocol could be run over the public Internet it
  was eventually run over the public Internet.
• We have explicit examples of this occurring -
  TDM PWs that are known to be running over the
  Internet.

3
PWE3 Charter

• Whilst a service provider may traffic engineer
  their network in such a way that PW traffic will
  not cause significant congestion, a PW deployed
  by an end-user may causecongestion of the
  underlying PSN. Suitable congestion avoidance
  mechanisms are therefore needed to protect
  theinternet from the unconstrained deployment of
  PWs.

4
Requirements

• RFC 3916 (Requirements for Pseudo-Wire Emulation
  Edge-to-Edge (PWE3)) says nothing about
  congestion.
• RFC 4197 (Requirements for Edge-to-Edge Emulation
  of Time Division Multiplexed (TDM) Circuits over
  Packet Switching Networks ) says
• TDM circuits run at a constant rate, and hence
  offer constant traffic loads to the PSN. The rate
  varying mechanism that TCP uses to match the
  demand to the network congestion state is,
  therefore, not applicable.
• The ability to shut down a TDM PW when congestion
  has been detected MUST be provided.
• Precautions should be taken to avoid situations
  wherein multiple TDM PWs are simultaneously shut
  down or re-established, because this leads to PSN
  instability.
• Further congestion considerations are discussed
  in chapter 6.5 of RFC3985.

5
Architecture

• RFC 3985 (PW Architecture) says
• The PSN carrying the PW may be subject to
  congestion which will vary with the PSN type, the
  network architecture and configuration, and the
  loading of the PSN.
• If the traffic carried over the PW is known to be
  TCP friendly no additional congestion avoidance
  action is necessary.
• If the PW is operating over a PSN that provides
  enhanced delivery, the PEs should monitor packet
  loss to ensure that the requested service is
  actually being delivered.
• If it is not, then the PE should assume that the
  PSN is providing a best-effort service and should
  use a best-effort service congestion avoidance
  measure.
• If best-effort service is being used and the
  traffic is not known to be TCP friendly, the PEs
  should monitor packet loss to ensure that the
  loss rate is within acceptable parameters. Packet
  loss is considered acceptable if a TCP flow
  across the same network path and experiencing the
  same network conditions would achieve an average
  throughput, measured on a reasonable timescale,
  not less than that which the PW flow is
  achieving.
• This condition can be satisfied by implementing
  a rate-limiting measure in the NSP, or by
  shutting down one or more PWs.
• The choice of which approach to use depends upon
  the type of traffic being carried.
• Where congestion is avoided by shutting down a
  PW, a suitable mechanism must be provided to
  prevent it from immediately returning to service
  and causing a series of congestion pulses.
• The comparison to TCP cannot be specified exactly
  but is intended as an "order-of-magnitude"
  comparison in timescale and throughput. The
  timescale on which TCP throughput is measured is
  the round-trip time of the connection. In
  essence, this requirement states that it is not
  acceptable to deploy an application (using PWE3
  or any other transport protocol) on the
  best-effort Internet, which consumes bandwidth
  arbitrarily and does not compete fairly with TCP
  within an order of magnitude.
• One method of determining an acceptable PW
  bandwidth is described in RFC3448.

6
The Encapsulation Drafts

• The packet and ATM Encapsulation drafts say
  little about congestion, other than to reference
  RFC3985.
• The TDM drafts introduce the special
  considerations that apply to TDM, but do not
  provide a congestion avoidance design.

7
ATM draft

• draft-ietf-pwe3-atm-encap-11.txt
• DISCUSS RFC3985 also says "Where congestion is
  avoided by shutting down a PW, a suitable
  mechanism must be provided to prevent it from
  immediately returning to service and causing a
  series of congestion pulses.
• I don't see such a mechanism in this draft.
• Discuss resolved by agreeing that PWE3 WG should
  work on the issue of congestion.

8
PWE3 work on congestion

• The only attempt to address the PWE3 congestion
  has been the draft
• PWE3 Congestion Control Framework
  draft-rosen-pwe3-congestion-03.txt
• Which we summarise in the next

9
Congestion Control and PWE3

• Congestion
• Everyone sends as much as they want
• less and less traffic gets through,
• because more and more is dropped
• Congestion Control
• Feedback loop
• packet loss causes transmission rates to go down
• absence of packet loss allows rates to climb

10
Does PWE3 Need It?

• No, PWE3 mostly carries IP payloads, already
  congestion controlled
• No, PWE3 only runs in environments in which
  congestion is impossible
• Never on public Internet
• Always traffic engineered and policed
• First point worth considering, second seems
  doubtful.
• So maybe answer is yes.

11
Existing Solutions Apply?

• Existing solutions aimed at endsystem
  implementations
• PWE3 aimed at router implementation
• No acks
• No complex state machines invoked in the data
  path
• Limited interactions between
• hardware and software,
• between line cards,
• between line cards and central processor, etc.
• Rules out, e.g., use of TCP to carry PWs
• And much else

12
Detecting Congested PWs

• By sequence number gaps problematic
• Periodic marking of PW data stream
• VCCV packets with transmit counts (inserted by
  hardware just before transmission??)
• Receiving hardware inserts receive count and
  passes to processor
• Report discrepancies via control plane, perhaps
  per-tunnel
• Per-tunnel approximation??

13
Responding to Loss

• AIMD vs. TFRC vs. ??
• TFRC is slower responding, and rate based, may be
  more appropriate
• Dont want response too slow, but really dont
  want false alarms
• Why TCP friendly?
• May be on Internet
• An SP may have paying non-PWE3 customers
• Adjusting rates on TDM PWs
• Selective stopping of channels?

14
Proposal

• Adopt draft-rosen-pwe3-congestion-03.txt as a WG
  draft and use as a framework for the congestion
  solution.
• Form a design team consisting of PWE3, L2TP and
  Congestion experts to write a protocol draft to
  address the PWE3/L2TPv3 congestion problem