Upload
minnie
View
27
Download
0
Embed Size (px)
DESCRIPTION
P re- C ongestion N otification (PCN) BOF 67th IETF, San Diego, CA BOF Chairs: Anna Charny Scott Bradner. 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) - PowerPoint PPT Presentation
Citation preview
1
Pre-Congestion Notification (PCN)BOF 67th IETF, San Diego, CA
BOF Chairs:
Anna CharnyScott 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
BTS
MSC
PCN
V
V
PCN-enabled Gateway
PCN-enabled Routers
V
BTS
MSC
PCN-enabled Gateway
• PCN Edge = VoIP Trunk Gateway• VoIP Trunk GW handles high number of calls• All per-flow state restricted to VoIP Gateways
Edge-Edge PCN Example
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)?
Flow admission / pre-emption decision at edges
Packets Marked at router interfaces
PCN
V
V
PCN-enabled Gateway
PCN-enabled Routers
V
PCN-enabled Gateway
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 What’s 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 can’t enter unless part of an admitted flow
(for traffic in PCN’s 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
PCN
PCN-enabled Routers
PCN-enabled Gateway
PCN-enabled Gateway
26
SIP Controlled Flow Admission and Preemption
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
PCN-enabled Routers
PCN-enabled
End Point
PCN-enabled Gateway
CS
CS
SIP Call Server
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:
1. a Problem Statement, to describe the problems the group is tackling and the assumptions made
2. 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)
3. 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.
4. 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
5. 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:
1. 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
2. By assuming there are many flows on any bottleneck link in the PCN-enabled region.
38
Proposed Charter (8)
3. 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].
4. 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?