PRESENTATION TITLE - By [Author Name] [email id] - PowerPoint PPT Presentation

About This Presentation
Title:

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

Description:

– PowerPoint PPT presentation

Number of Views:51
Avg rating:3.0/5.0
Slides: 44
Provided by: ietf
Learn more at: https://www.ietf.org
Category:

less

Transcript and Presenter's Notes

Title: 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?
Write a Comment
User Comments (0)
About PowerShow.com