PRESENTATION TITLE - By [Author Name] [email id]

1
Pre-Congestion Notification (PCN) BOF 67th
IETF, San Diego, CA BOF Chairs Anna
Charny Scott Bradner
2
Agenda

• Agenda bashing and administrativia (5 min, Scott)
  
• Overview and Introduction (20 min, Anna)
• Key Open Issues (10 min, Phil )
• Overview of existing work (10 min, Kwok)
• Open Discussion on PCN (20 min, Scott)
• Proposed Charter (20 min, Anna)
• Discussion of Proposed Charter (20 min, Scott)
• Summary and conclusions (10 min, Scott)

3
Agenda

• Agenda bashing and administrativia (5 min Scott)
  
• Overview and Introduction (20 min, Anna)
• Key Open Issues (10 min, Phil )
• Overview of existing work (10 min, Kwok)
• Open Discussion on PCN (20 min, Scott)
• Proposed Charter (20 min, Anna)
• Discussion of Proposed Charter (20 min, Scott)
• Summary and conclusions (10 min, Scott)

4
Introduction

• What is PCN
• Why it is a technical problem of interest
• Why it is an IETF Problem
• See draft-chan-pcn-problem-statement for more
  detail

5
What is Pre-Congestion Notification?

• Scalable, resilient admission control using
  packet marking techniques
• Two parts Admission (for normal situations)
  and flow Pre-emption (for unusual situations,
  e.g. failures)
• Core nodes
• measure current load of admission-controlled
  traffic
• selectively mark packets if congestion appears
  imminent (hence pre-congestion)
• Edge nodes
• monitor marking between PCN ingress-egress pairs
• may not admit new flows, or drop (pre-empt)
  existing ones based on marking of packets

6
Edge-Edge PCN Example

• PCN Edge VoIP Trunk Gateway
• VoIP Trunk GW handles high number of calls
• All per-flow state restricted to VoIP Gateways

PCN-enabled Gateway
PCN-enabled Routers
PCN-enabled Gateway
PCN
7
Admission Control When is it Needed?

• Resource-Based Call Admission Control (CAC) may
  be useful in some environments
• On bottleneck links
• When over-provisioning is expensive (a lot of
  real time traffic) and/or difficult to get right
  (aggregate load hard to predict)
• Voice Trunking in PSTN/Mobile environments
• Video on Demand
• For non-routine situations (e.g. flash crowds)

8
Coping with Failures

• Provisioning against failures is expensive even
  for single failures
• Much more expensive for multiple failures
• When reroutes occur (e.g. due to failures), all
  real-time traffic on affected links may get
  degraded QoS
• Better remove (pre-empt) some previously admitted
  flows to maintain QoS for the remaining ones
• Admission by itself may not be sufficient under
  failures
• Admission and Pre-emption can be used
  independently of each other

9
Why Is Yet Another CAC Needed?

• Prior RSVP-based solutions of various degrees of
  scalability
• RFC2208
• Aggregate RSVP reservations (RFC3175)
• draft-lefaucheur-rsvp-dste-02.txt,
  draft-lefaucheur-rsvp-ipsec
• Reservations-based RMD
• No state in the core, per-hop signaling
• PCN next step in scalability reduction coupled
  with strong QoS assurances
• No state, no signaling in the core
• Many concepts common with aspects of
  marking-based RMD work in NSIS

10
State of Maturity

• PCN builds on substantial body of prior
  theoretical work on measurement-based CAC
• Substantial work of PCN Design team within TSVWG
• to be discussed by Kwok Ho Chan

11
Why is this an IETF Problem?

• We believe that PCN is a viable approach to
  scalable admission control
•  PCN requires certain things to be standardized 
• e.g. How to mark pre-congestion in packets, etc.
•  We believe that the research on PCN has
  progressed to the stage that standardization is
  now reasonable
•  

12
What Would a Working Group Do?

• Some Open Issues
• Some technical issues remain and need to be
  tackled
• E.g. how much aggregation is enough
• Some depend on deployment models
• A number of open standardization issues
• E.g. how marking is encoded how much of marking
  algorithms require standardization
• Details to be discussed by Phil Eardley
• Community consensus on deployment models of
  interest needed to focus the effort
• Interact with other working groups

13
Connections with Other Groups

• ECN compatibility RFC3168 (tsv)
• Signaling extensions
• RSVP (tsv)
• NSIS (nsis)
• SIP (mmusic)
• PCN over MPLS (tsv and/or mpls?)
• Applicability to pseudowire congestion control?
  (pwe3)
• Ensuring emergency services can be supported on
  top of PCN (ieprep and ecrit)

14
Summary

• There is a legitimate technical problem
• There is need of standardization effort
• The solution is sufficiently mature
• There are a bounded number of open issues needing
  resolution

15
Agenda

• Agenda bashing and administrativia (5 min, Scott)
  
• Overview and Introduction (20 min, Anna)
• Key Open Issues (10 min, Phil )
• Overview of existing work (10 min, Kwok)
• Open Discussion on PCN (20 min, Scott)
• Proposed Charter (20 min, Anna)
• Discussion of Proposed Charter (20 min, Scott)
• Summary and conclusions (10 min, Scott)

16
Open issues

• Standardization issues
• Technical issues

17
Standardization Issues

• Develop standards track solutions to the
  following problems
• 1. When should an interior router mark a packet
  (i.e. at what traffic level) in order to give
  early warning of its own congestion?
• 2. How should such a mark be encoded in a packet
  (in the ECN and/or DSCP fields)?
• 3. How should these markings (at packet
  granularity) be converted into admission control
  and flow pre-emption decisions (at flow
  granularity)?

Packets Marked at router interfaces
PCN-enabled Routers
PCN-enabled Gateway
PCN-enabled Gateway
PCN
Flow admission / pre-emption decision at edges
18
Detail of Standardization?

• Goal of standardization is that compliant
  implementations work together properly
• Easy to implement
• Solution delivers effective admission control
  flow pre-emption
• Whats the right level of detail for the router
  marking standard?
• Implementation? (must use virtual queue)
• Algorithm? (use this formula)
• Behaviour? (produce this behaviour measured
  externally, as in DiffServ)
• Do we standardize one edge behaviour for
  admission control one for pre-emption?
• Different edge reactions may be better for
  different deployment models
• But complex? (negotiate to discover which to use,
  interoperability issues)
• Current consensus one for each is probably
  possible.

No!
19
Focussing the Work

• In order to focus the standardisation work we
  need to get
• Community consensus on the deployment models
• Kwok will talk about
• Community consensus on the assumptions
• Controlled environment / trust
• However, allow enough flexibility so that
  solutions can be defined after re-chartering
  where trust assumptions are different
• Aggregation (multi-flows) on interior routers
• Real-time, inelastic applications (Controlled
  load service)
• Standardisation of the use of PCN for Emergency
  services is out of scope
• However, the above statement does not preclude
  the use of PCN in emergency or different
  precedence services.
• If necessary would re-charter to widen the scope

20
Controlled environment / trust assumption

• Assume the PCN-enabled Internet Region is a
  controlled environment, i.e. all the interior
  routers and edge nodes of the region run PCN and
  trust each other
• Ring of Edge nodes surround PCN-region
• ensure packets cant enter unless part of an
  admitted flow (for traffic in PCNs DiffServ
  class)
• Trust that all nodes (in PCN-region) run PCN
• all routers mark packets correctly
• Is there community consensus on this assumption?
• largely avoids cheating issues until re-chartering

21
Emergency services out of scope assumption

• Discussion on ML reached consensus on adding an
  extra assumption
• Keep specific handling of emergency and other
  precedence (911, GETS, WPS, MLPP etc.) calls out
  of scope of the WG while (a) ensuring that the
  edge nodes are not precluded from taking
  appropriate actions that may be necessary for
  handling such calls and (b) assuming that PCN
  Internal Nodes may not be MLPP precedence-aware
  but are DSCP aware.
• Is there community consensus to add this
  assumption?

22
Technical Issues

• Compatibility of encoding with RFC 3168
• Several known technical tradeoffs
• e.g. sub-optimality in the presence of ECMP,
  bi-directional flows for pre-emption
• WG needs to reach consensus on the extent to
  which the standardization effort should address
  those

23
Agenda

• Agenda bashing and administrativia (5 min, Scott)
  
• Overview and Introduction (20 min, Anna)
• Key Open Issues (10 min, Phil )
• Overview of existing work (10 min, Kwok)
• Open Discussion on PCN (20 min, Scott)
• Proposed Charter (20 min, Anna)
• Discussion of Proposed Charter (20 min, Scott)
• Summary and conclusions (10 min, Scott)

24
Contents

• Controlled Load Deployment Model
• SIP Controlled Flow Admission and Preemption
  Deployment Model
• Measurement and Encoding at Interior Router
• Current PCN related drafts

25
Controlled Load Deployment Model

• Interior Nodes provide via packet marking network
  resource utilization information based on their
  local measurement.
• Edge Nodes use information from Interior Nodes
  for making Flow Admission and Preemption
  decisions.
• Usage of RSVP between CL Edge Nodes for
  communicating Flow Admission and Preemption
  information.
• draft-briscoe-tsvwg-cl-architecture-04.txt

26
SIP Controlled Flow Admission and Preemption
CS
SIP Call Server
PCN-enabled Gateway

• Interior Nodes provide via packet marking network
  resource utilization information based on their
  local measurement.
• End/Edge Nodes pass the marking information from
  Interior Nodes to SIP functional elements for
  making Session Admission and Preemption
  decisions.
• draft-babiarz-pcn-sip-cap-00.txt

PCN-enabled Routers
PCN
PCN-enabled End Point
27
Measurement and Encoding at Interior Router

• Existing work in draft-briscoe-tsvwg-cl-phb-03.txt
  
• Traffic measurement method
• Measures aggregated traffic
• For admission control and preemption
• Example of packet marking method for
• Admission control and Preemption
• Analysis of different measurement approaches
• Keeping the measurement at Interior Nodes simple
• Analysis of different packet marking approaches
  using ECN field or combination of ECN field and
  DSCP
• Simulation Work
• draft-zhang-pcn-performance-evaluation-00.txt
• http//standards.nortel.com/pcn/simulation_results
  _00.pdf

28
PCN Related Drafts

• draft-chan-pcn-problem-statement-01.txt
• draft-briscoe-tsvwg-cl-phb-03.txt
• draft-briscoe-tsvwg-cl-architecture-04.txt
• draft-babiarz-pcn-sip-cap-00.txt
• draft-charny-pcn-single-marking-00.txt
• draft-zhang-pcn-performance-evaluation-00.txt

29
Agenda

• Agenda bashing and administrativia (5 min, Scott)
  
• Overview and Introduction (20 min, Anna)
• Key Open Issues (10 min, Phil )
• Overview of existing work (10 min, Kwok)
• Open Discussion on PCN (20 min, Scott)
• Proposed Charter (20 min, Anna)
• Discussion of Proposed Charter (20 min, Scott)
• Summary and conclusions (10 min, Scott)

30
Agenda

• Agenda bashing and administrativia (5 min, Scott)
  
• Overview and Introduction (20 min, Anna)
• Key Open Issues (10 min, Phil )
• Overview of existing work (10 min, Kwok)
• Open Discussion on PCN (20 min, Scott)
• Proposed Charter (20 min, Anna)
• Discussion of Proposed Charter (20 min, Scott)
• Summary and conclusions (10 min, Scott)

31
Proposed Charter (1)

• The PCN WG will tackle the problem of how to
  provide scalable, resilient admission control and
  strong QoS assurance while using packet marking
  techniques.
• Current attempts to deliver QoS using only
  packet marking (e.g. DiffServ) are limited in the
  level of QoS assurance that can be provided
  without substantial over-provisioning. To improve
  the QoS assurance, PCN will add flow admission
  control and flow pre-emption. In normal
  circumstances admission control should protect
  the QoS of previously admitted flows. In times of
  heavy congestion (for example caused by route
  changes due to link or router failure)
  pre-emption of some flows should preserve the QoS
  of remaining flows. While the WG will address
  both admission and pre-emption, it is assumed
  that these mechanisms can be used independently
  of each other, and the use of one does not
  mandate the use of the other.

32
Proposed Charter (2)

• The initial scope of the WG is the use of PCN
  within a single DiffServ region.
• The overall approach will be based on a
  separation of functionality between the interior
  routers and edge nodes of the DiffServ region.
  Interior routers mark packet headers when their
  traffic is above a certain level, as an early
  warning of incipient congestion
  (pre-congestion) this builds on concepts from
  The Addition of Explicit Congestion Notification
  to IP (RFC 3168). Edge nodes of the DiffServ
  Region monitor the markings and that information
  is used to make flow admission control and
  pre-emption decisions. The decisions could be
  made by the edge nodes or by a centralized system
  (which is informed of the edge nodes
  measurements).

33
Proposed Charter (3)

• The WG will address the following specific
  problems and develop standards track solutions to
  them
• 1. When should an interior router mark a packet
  (i.e. at what traffic level) in order to give
  early warning of its own congestion?
• 2. How should such a mark be encoded in a packet
  (in the ECN and/or DSCP fields)?
• 3. How should these markings (at packet
  granularity) be converted into admission control
  and flow pre-emption decisions (at flow
  granularity)?

34
Proposed Charter (4)

• To support this, the WG will work on the
  following Informational documents
• a Problem Statement, to describe the problems the
  group is tackling and the assumptions made
• at least two deployment models, initially to help
  focus the problem statement and later to check
  that the solutions being developed satisfy the
  deployment scenario. (continued)

35
Proposed Charter (5)

• Possible deployment models may be
• IntServ over DiffServ (RFC2998) the DiffServ
  region is PCN-enabled and its edge nodes decide
  about admission and flow pre-emption
• SIP Controlled Admission and Preemption routers
  within the DiffServ region are PCN-capable and
  trusted SIP endpoints (gateway or host) perform
  admission and flow pre-emption
• Pseudowire PCN may be used as a congestion
  avoidance mechanism for end-user deployed
  pseudowires (collaborate with the PWE3 WG)

36
Proposed Charter (6)

• a generic analysis of the signaling extensions
  required to support PCN. Note that
  extensions/enhancements to specific signaling
  protocols (e.g. RSVP, NSIS, SIP) will not be done
  in the PCN WG.
• at least one example solution implementing the
  framework and its performance evaluation (e.g.
  simulation results), to provide evidence of the
  viability of the proposed standard in the
  proposed deployment models
• an analysis of the tradeoffs of different
  encoding possibilities (e.g. ECN and DCSP
  marking)

37
Proposed Charter (7)

• The initial scope of the WG will restrict the
  problem space in the following ways
• By assuming the PCN-enabled Internet Region is a
  controlled environment, i.e. all the interior
  routers and edge nodes of the region run PCN and
  trust each other
• By assuming there are many flows on any
  bottleneck link in the PCN-enabled region.

38
Proposed Charter (8)

• By focusing on the QoS assurance required by real
  time applications generating inelastic traffic
  like voice and video requiring low delay, jitter
  and packet loss, i.e. as defined by the
  Controlled Load Service RFC2211.
• By keeping specific handling of emergency and
  other precedence (911, GETS, WPS, MLPP etc.)
  calls out of scope of the WG while
• ensuring that the edge nodes are not precluded
  from taking appropriate actions that may be
  necessary for handling such calls
• assuming that PCN Internal Nodes may not be MLPP
  precedence-aware but are DSCP aware.

39
Proposed Charter (9)

• Subsequent re-chartering may investigate
  solutions for when some of these restrictions are
  not in place.
• Topics out of scope for the WG include a general
  investigation of admission control mechanisms.
• The WG will draw on the substantial prior
  academic and IETF work on measurement-based
  admission control.

40
Proposed Charter (10)

• Milestones
• Nov 2006 initial Problem statement
• Nov 2006 initial deployment models
• March 2007 initial router marking behavior
  (including encoding)
• March 2007 initial flow admission control and
  pre-emption mechanism (including edge node
  behavior)
• March/July 2007 submit Problem statement
• March/July 2007 submit deployment models
• Nov 2007 submit router marking behavior
• Nov 2007/Mar 2008 submit flow admission control
  and pre-emption mechanism
• Nov 2007 initial signaling analysis
• Mar 2008 re-charter or close

41
Agenda

• Agenda bashing and administrativia (5 min Scott)
  
• Overview and Introduction (20 min, Anna)
• Key Open Issues (10 min, Phil )
• Overview of existing work (10 min, Kwok)
• Open Discussion on PCN (20 min, Scott)
• Proposed Charter (20 min, Anna)
• Discussion of Proposed Charter (20 min, Scott)
• Summary and conclusions (10 min, Scott)

42
Agenda

• Agenda bashing and administrativia (5 min Scott)
  
• Overview and Introduction (20 min, Anna)
• Key Open Issues (10 min, Phil )
• Overview of existing work (10 min, Kwok)
• Open Discussion on PCN (20 min, Scott)
• Proposed Charter (20 min, Anna)
• Discussion of Proposed Charter (20 min, Scott)
• Summary and conclusions (Scott)

43
Summary

• A Legitimate Technical Problem
• Need for Standardization
• Sufficient Maturity of Solution
• A number of Open Issues
• Is there a Consensus that a WG is Needed to work
  within the scope of the proposed charter?