PCN Draft Charter (Pre-Congestion Notification)
 
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.  

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 
RFC 3168 "The Addition of Explicit Congestion Notification to IP". 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). 

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)?
 
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. Possible deployment models may be: 
   (a) IntServ over DiffServ (RFC2998): the DiffServ region is PCN-enabled 
       and its edge nodes decide about admission and flow pre-emption
   (b) Application-controlled Admission and Pre-emption: routers within
       the DiffServ region are PCN-capable and trusted application-controlled 
       (e.g., SIP) endpoints (gateway or host) based on the marking, perform 
       admission and flow pre-emption.
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)
6. an applicability statement (the decision on whether applicability statement 
   will be delivered as a standalone document or will be incorporated into other
   documents such as deployment models is TBD)
7. an analysis of the manageability issues of a PCN region
 
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 sufficient flows on any relevant bottleneck link in the 
   PCN-enabled region 
3. By focusing on the QoS assurance required by 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 (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.

Subsequent re-chartering may investigate solutions for when some of these 
restrictions are not in place. 
In particular, after re-chartering it's expected that the WG will cover
the case with multiple, non-trusting domains. However, even during the
initial standardisation phase, this case needs to be kept in mind, as
the anti-cheating solution will impact on e.g. the choice of encoding.
 

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.

The WG will work with relevant IETF WGs and, where appropriate, with external groups.
 
Milestones:

Nov 2006          initial problem statement Internet Draft
Nov 2006          initial deployment models Internet Drafts
March 2007        initial router marking behavior (including encoding) Internet Drafts
March 2007        initial flow admission control and pre-emption mechanisms Internet Drafts
                  (including edge node measurements)
March 2007        initial applicability statement Internet Draft
March/July 2007   submit Problem statement to IESG for approval as informational RFC
July 2007         submit deployment models to IESG for approval as informational RFC
July 2007         submit applicability statement to IESG for approval as informational RFC
                  (may be part of the deployment models)
July 2007         initial manageability issues document Internet Draft
Nov 2007          submit router marking behavior to IESG for approval as standards track RFC
Nov 2007/Mar 2008 submit flow admission control and pre-emption mechanism as standard track RFC
Nov 2007          initial signaling analysis Internet Draft 
Nov 2007          submit manageability issues document to IESG for approval as informational RFC
Mar 2008          re-charter or close