Subject: [PCN] PCN updated charter

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Fri, 24 Nov 2006 11:43:05 -0500

Dear all,
 
The proposed PCN charter has been updated based on the (very few) recent
comments we received.
The new version has been uploaded, and is also attached at the end of
this email for convenience.

The only difference from the previously posted version is a wording
change below:

2.
  ....
  (b) Application-controlled Admission and Pre-emption: routers within
        the DiffServ region are PCN-capable and trusted e.g. SIP
endpoints
        (gateway or host) perform admission and flow pre-emption  
 
TO:
2.
  .....
  (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.

If you had sent us any email with proposed changes that was
inadvertently missed and not reflected,
please let us know right away.

Best Regards,
Anna and Scott
PCN BOF Co-Chairs

-------------

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 standardization 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

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 Nov 2006 17:44:35 +0100

Hi Anna,

obviously the milestones are not realistic.

Ciao
Hannes

---

From: Lars Eggert <[email-masked]>
Date: Tue, 28 Nov 2006 18:17:14 -0800

Hi,

I think feedback on PCN in San Diego was overall mostly positive, and  
a large reason was that the BOF was really well prepared and chaired.  
Nice job!

However, some discussions in and after San Diego brought up valid  
points that a revised charter should reflect. Let me briefly outline  
them below, so we can start discussing them here:

(1) Both the SIP- and PWE3-related deployment models have been  
questioned by the respective communities, and will require non- 
trivial coordination to align with the existing work in those areas.  
I'd therefore like to propose to exclude them from the initial scope  
of PCN at this time, and limit PCN to the "IntServ over DiffServ"  
case at this time.

(2) The different options of encoding markings in packets require  
further investigation. This is an important component, because the  
deployability of PCN hinges on well-defined marking mechanisms. I'd  
therefore like to propose that PCN in the first phase should focus  
its energies on working on the problem statement, deployment model  
and marking mechanisms only. Work on the actual admission and  
preemption mechanisms should kick off only after these initial work  
items are stable.

Comments?

Thanks,
Lars

---

From: ken carlberg <[email-masked]>
Date: Tue, 28 Nov 2006 21:53:11 -0500

Lars,

> preemption mechanisms should kick off only after these initial work  

I'd like to advocate against having a problem statement deliverable.   
Normally, for new WGs the standard approach is a problem statement,  
usually a requirements, and then whatever (architecture, BCP, etc.).   
But in this case, we have a number of pre-existing documents  
(including an architecture) that have already gone through some  
discussions and presentations in TSVWG....so in my mind, there is a  
measure of a known problem space and approach that is relatively  
mature.  In addition, given your more narrow scope for the group, we  
have more focus.

So from my perspective, the exercise of a problem statement (in this  
particular case) would result in the group going a in lateral  
direction with not much of a contribution to existing drafts/work.

my 2 cents,

-ken

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 29 Nov 2006 10:27:15 +0100

Hi Lars

Regarding the SIP based deployment model, from what I 
remember there was a consensus to concentrate on an application 
based deployment model, instead of concentarting on a 
SIP deployment model. SIP could be then used as an example.

However, we could concentrate on the application based 
deployment model without using SIP as a signaling application example.

What is your opinion on this?

Best Regards,
Georgios

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: woensdag 29 november 2006 3:17
> To: [email-masked]
> Subject: Re: [PCN] PCN updated charter
> 
> Hi,
> 
> I think feedback on PCN in San Diego was overall mostly 
> positive, and a large reason was that the BOF was really well 
> prepared and chaired.  
> Nice job!
> 
> However, some discussions in and after San Diego brought up 
> valid points that a revised charter should reflect. Let me 
> briefly outline them below, so we can start discussing them here:
> 
> (1) Both the SIP- and PWE3-related deployment models have 
> been questioned by the respective communities, and will 
> require non- trivial coordination to align with the existing 
> work in those areas.  
> I'd therefore like to propose to exclude them from the 
> initial scope of PCN at this time, and limit PCN to the 
> "IntServ over DiffServ"  
> case at this time.
> 
> (2) The different options of encoding markings in packets 
> require further investigation. This is an important 
> component, because the deployability of PCN hinges on 
> well-defined marking mechanisms. I'd therefore like to 
> propose that PCN in the first phase should focus its energies 
> on working on the problem statement, deployment model and 
> marking mechanisms only. Work on the actual admission and 
> preemption mechanisms should kick off only after these 
> initial work items are stable.
> 
> Comments?
> 
> Thanks,
> Lars
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Nov 2006 08:23:37 -0800

Hi, Ken,

On Nov 28, 2006, at 18:53, ken carlberg wrote:
> I'd like to advocate against having a problem statement  
> deliverable.  Normally, for new WGs the standard approach is a  
> problem statement, usually a requirements, and then whatever  
> (architecture, BCP, etc.).  But in this case, we have a number of  
> pre-existing documents (including an architecture) that have  
> already gone through some discussions and presentations in  
> TSVWG....so in my mind, there is a measure of a known problem space  
> and approach that is relatively mature.  In addition, given your  
> more narrow scope for the group, we have more focus.
>
> So from my perspective, the exercise of a problem statement (in  
> this particular case) would result in the group going a in lateral  

I came up with the initial milestones by selecting a subset if the  
ones on the current draft charter at http://standards.nortel.com/pcn/ 
PCN_draft_charter_v01.txt, which does have a "problem statement" listed.

But I see your point, and maybe PCN wants to discuss replacing that  
milestone with an architecture document that also describes the  
problem space and requirements for the individual marking and  
admission/preemption mechanisms to be developed later?

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Nov 2006 08:26:12 -0800

Hi, Georgios,

> What is your opinion on this?

I'm not sure what you mean by "application-based deployment model."

These three models were discussed in the PCN BOF and are also in the  
current charter:

>    (a) IntServ over DiffServ (RFC2998): the DiffServ region is PCN- 
> enabled
>    (b) 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
>    (c) Pseudowire: PCN may be used as a congestion avoidance  
> mechanism for
>        end-user deployed pseudowires (collaborate with the PWE3 WG)

I was arguing to restrict the initisal scope to (a) only.

Lars

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 29 Nov 2006 17:58:02 +0100

Hi Lars

During the PCN BOF, concerns have been expressed on 
the "SIP based deployment model", but several opinions 
were in favour of including in the PCN charter 
instead of the "SIP based deployment model" an
"Application based deployment model". 
Thus the (b) deployment model has to be redefined and 
presented as the "Application based deployment model", 
where SIP could be seen as an example.

Please note that also the RU-PDB concept (presented 
during the tsvwg meeting) could be seen as an 
"Application based deployment model".
Please see some discussion on the tsvwg mailing 
list on this (that took place during the IETF meeting 
in San Diego).

Best Regards,
Georgios

> Sent: woensdag 29 november 2006 17:26
> To: [email-masked]
> remember there 
> > was a consensus to concentrate on an application based deployment 
> > model, instead of concentarting on a SIP deployment model. 
> SIP could 
> > be then used as an example.
> >
> > However, we could concentrate on the application based deployment 
> > model without using SIP as a signaling application example.
> >
> These three models were discussed in the PCN BOF and are also 
> in the current charter:
> 
> >    (c) Pseudowire: PCN may be used as a congestion 
> avoidance mechanism 
> > for

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Nov 2006 09:04:30 -0800

Hi,

> where SIP could be seen as an example.

I fail to see how broadening this deployment model from "SIP only" to  
"arbitrary applications, SIP one example" is making it easier to make  
progress. The general problem will be harder to solve, and with SIP  
as an example the SIP details still would need to be gotten right.

Lars

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 29 Nov 2006 16:26:48 -0500

Hi Lars, 

On the deployment models, I believe that it is important for the
pre-congestion mechanism to be tested against more than one deployment
scenario or technology. ITEF needs to generate protocols that are
generic and have wide applicability. My understanding from the BOF was
that SIP-controlled admission and preemption model needs to be made more
generic with SIP as an example. For admission control and preemption to
work properly there needs to be information passed to the application as
it needs to know when it can start to sending packets (session setup
successful) or when it must stop (session needs to be terminated).

I do not believe much coordination is required between PCN WG and any of
the WGs that are currently working on signaling related protocols. My
view is that once the PCN WG has agreed on the pre-congestion marking
mechanism, than any needed changes to signaling protocols, RSVP, SIP
meaning SDP extensions, etc. would be submitted as a draft to the
appropriated WG. 

I support that the application-control admission control deployment
model to be in the PCN WG charter. 

Regards, Joe
Telephone: 613-763-6098 
Email: [email-masked]
-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: Tuesday, November 28, 2006 9:17 PM
To: [email-masked]
Subject: Re: [PCN] PCN updated charter

Hi,

Comments?

Thanks,
Lars

---

From: Lars Westberg <[email-masked]>
Date: Thu, 30 Nov 2006 08:17:30 +0100

commenst inline

> as an example the SIP details still would need to be gotten right. 

I have the opposite problem. By limitating the deoplyment model, the 
applicabillity will be so narrow so the the working group may not 
consider deployment scenarios that are more general applicable that just 
a single one.

A deployment scenarion that assume that the whole world will use 
RSVP-signalling seems for me very strange. We have plenty of operator 
discussions and I haven't seen anyone that have been committed to use 
RSVP as it is proposed into that deployment scenario.

The assumption that the admission control should be implemented in a 
router is for me very strange. This may be of interest for som persons 
but not as a general way of solving a problem for the infrastructure. 
therefore a flexibillity of putting the admission contrl function 
outside the routed infrastructure should also be considered.

Was this actually aggreed on the BOF ?

---

From: <[email-masked]>
Date: Thu, 30 Nov 2006 13:52:05 -0000

I don't think the RSVP /signalling aspects of the deployment model are the important bits - what matters is the impact on the assumptions/goals as they affect PCN. 
phil

-----Original Message-----
From: Lars Westberg [mailto:[email-masked]] 
Sent: 30 November 2006 07:18
To: Lars Eggert
Cc: [email-masked]; "Attila Báder (IJ/ETH)"
Subject: Re: [PCN] PCN updated charter

commenst inline

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 30 Nov 2006 15:41:45 +0100

Hi Phil

It is important to note that when only one 
deployment model is used then the assumptions/goals 
that affect the PCN activities will be 
too limited. Meaning that we might find other PCN 
solutions when we consider two deployment models 
instead of one.

Best Regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: donderdag 30 november 2006 14:52
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [PCN] PCN updated charter
> 
> I don't think the RSVP /signalling aspects of the deployment 
> model are the important bits - what matters is the impact on 
> the assumptions/goals as they affect PCN. 
> phil
> 
> >> During the PCN BOF, concerns have been expressed on the "SIP based 
> >> deployment model", but several opinions were in favour of 
> including 
> >> in the PCN charter instead of the "SIP based deployment model" an 
> >> Thus the (b) deployment model has to be redefined and presented as 
> >> the "Application based deployment model", where SIP could 
> be seen as 
> >> an example.
> >
> >
> > progress. The general problem will be harder to solve, and 
> with SIP as 
> > an example the SIP details still would need to be gotten right.
> 
> I have the opposite problem. By limitating the deoplyment 
> model, the applicabillity will be so narrow so the the 
> working group may not consider deployment scenarios that are 
> more general applicable that just a single one.
> 
> A deployment scenarion that assume that the whole world will 
> use RSVP-signalling seems for me very strange. We have plenty 
> of operator discussions and I haven't seen anyone that have 
> been committed to use RSVP as it is proposed into that 
> deployment scenario.
> 
> The assumption that the admission control should be 
> implemented in a router is for me very strange. This may be 
> of interest for som persons but not as a general way of 
> solving a problem for the infrastructure. 
> therefore a flexibillity of putting the admission contrl 
> function outside the routed infrastructure should also be considered.
> 
> >> Please note that also the RU-PDB concept (presented during 
> the tsvwg 
> >> meeting) could be seen as an "Application based deployment model".
> >> Please see some discussion on the tsvwg mailing list on this (that 
> >> took place during the IETF meeting in San Diego).
> >
> >
> > Lars
> >
> 
>

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 30 Nov 2006 11:34:50 -0500

Lars:
Please see my comments on your (1) in-line below.

With the bottom line at the top:
I am proposing TO KEEP the Application/SIP Deployment Model in the charter.

Thanks!
-- Kwok --

>of PCN at this time, and limit PCN to the "IntServ over DiffServ"

<Kwok_Start>
 From the Minutes of the BOF:
"Dave Oran: If it requires SIP to change, we have problems, but I 
doubt it does.
It has a dependency on SDP, which has the QoS pre-conditions."

The Application/SIP/SDP Deployment Model currently does NOT indicate any
changes required of SIP/SDP.  Hence I agree with Dave Oran on his point
of "I doubt it (the Application/SIP/SDP Deployment Model) does 
(requires SIP to change).
It has a dependency on SDP, which has the QoS pre-conditions."

With this point, the Application (SIP) usage of PCN mechanisms Deployment Model
will be using the SIP/SDP QoS pre-conditions.  Without changes to existing work
in the (SIP, SDP) area.
Hence does not see the point of "will require non-trivial 
coordination to align with
the existing work in those areas".

With this, I am proposing TO KEEP the Application/SIP Deployment 
Model in the charter.
<Kwok_End>