Subject: [PCN] PCN Charter proposal version 4

From: Magnus Westerlund <[email-masked]>
Date: Mon, 05 Feb 2007 16:32:46 +0100

Hi,

Below is the 4th version of the PCN charter. It contains some 
modifications in the beginning to try to be more explicit about the 
decomposition. Then I also incorporated some of Jozef's comments.

Cheers

Magnus

----

Congestion and Pre-Congestion Notification (PCN)

Chair(s):
    tbd

Transport Area Director(s):
    Magnus Westerlund <[email-masked]>
    Lars Eggert <[email-masked]>

Transport Area Advisor:
    Lars Eggert <[email-masked]>

Mailing Lists:
    General Discussion: [email-masked]
    To Subscribe: [email-masked]
    In Body: (un)subscribe
    Archive: http://www.ietf.org/mail-archive/web/pcn/index.html

Description of Working Group:

The Congestion and Pre-Congestion Notification (PCN) working group 
develops mechanisms to protect the quality-of-service of established 
flows within a DiffServ domain when congestion is imminent or existing. 
These mechanisms operate at the domain boundary, based on aggregated 
congestion and pre-congestion information from within the domain. The 
focus of the WG is on developing standards for the marking behavior of 
the interior nodes and the encoding transport of the congestion 
information. The transport and encoding of the congestion information is 
decompositioned into several components. The forward flow path to the 
domain boundary, the metering of the congestion situation at the 
boundary, and the transport of the data to the controlling peer. This 
decomposition is done to allow for future extensibility by defining 
additional variants of the components (with the exception of the first 
one). Reaction mechanisms at the boundary consist of flow admission and 
flow termination. Although designed to work together, flow admission and 
flow termination are independent mechanisms, and the use of one does not 
require or prevent the use of the other. In consultation with the AD, 
the WG may produce a small number of informational documents that 
describe how specific quality-of-service policies for a domain can be 
implemented using these two mechanisms.

The PCN WG will specify the following components to protect the 
quality-of-service of flows within a DiffServ domain:

    (1) a general architecture for flow admission and termination based
        on aggregated (pre-)congestion information

    (2) a specification of conditions under which interior nodes generate
        (pre-)congestion information

    (3) encoding and transport of (pre-)congestion information
        between the interior and the egress node of the domain

    (4) Metering of the (pre-)congestion information at the egress
        node of the domain.

    (5) encoding and transport of (pre-)congestion information
        between the egress node and the ingress node of the domain
        (when necessary).

    (6) ingress node control mechanisms for flow admission or termination,
        based on aggregated (pre-)congestion information

The WG focuses on the overall architecture, and specifically on the 
marking behavior and encoding and transport mechanisms needed to realize 
it. Standards-track protocols and mechanisms are only developed where 
necessary for interoperability. For other components of the 
architecture, the WG may document examples or provide recommended 
solutions in informational documents. The architecture document will be 
comprehensive, and include security, manageability and operational 
considerations. If this WG requires extensions or modifications to 
protocols that are products of other WGs, it may motivate their need and 
describe requirements in informational documents; design of such 
extensions and modifications will take place in the appropriate WGs.

The initial scope of the PCN WG is restricted by the following assumptions:

    (A) these components are deployed in a single DiffServ domain,
        where all boundary and interior nodes are PCN-enabled
        and mutually trust each other

    (B) all flows handled by these mechanisms are inelastic and
        constrained to a known maximum rate through policing or shaping

    (C) the number of flows across any potential aggregation bottleneck
        is sufficiently large for stateless, statistical mechanisms to be
        effective

    (D) flows may have different precedence, but the applicability
        of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.)
        is out of scope

After completion of the initial phase, the PCN WG may re-charter to 
develop solutions for scenarios where some of these restrictions are not 
in place. It may also re-charter to consider applying the PCN mechanisms 
to additional deployment scenarios (operation over concatenated DiffServ 
domains, PCN-aware application mechanisms, etc.). The WG may also 
consider to investigate additional response mechanisms that act on 
(pre-)congestion information. One example could be flow-rate adaptation 
(rather than flow admission/termination) during times of congestion. The 
details of these work items are outside the scope of the initial phase; 
but the WG may consider their requirements to design components that are 
sufficiently general to support such extensions in the future.

Goals and Milestones:

Nov 2007   Flow Admission and Termination Architecture
            (Informational)

Nov 2007   Survey of Encoding and Transport Choices of
            (Pre-)Congestion Information within a DiffServ Domain
            (Informational)

Mar 2007   Flow Admission and Termination within a DiffServ
            Domain (Informational)

Mar 2007   (Pre-)Congestion Detection within a DiffServ Domain
            (Proposed Standard)

Mar 2008   Requirements for Signalling of (Pre-)Congestion information
             from Egress to Ingress Nodes in a DiffServ Domain
            (Informational)

Jul 2008   Encoding and Transport of (Pre-)Congestion Information
            from within a DiffServ Domain to the Egress
            (Proposed Standard)

Nov 2008   Encoding and Transport of (Pre-)Congestion Information
            from the Domain Egress to the Ingress
            (Proposed Standard)

Jul 2008   Suggested Flow Admission and Termination Boundary Mechanisms
            (Informational)

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Mon, 5 Feb 2007 13:55:58 -0500

I think it was good to add to the milestones the 'Requirements for
Signaling of (Pre-)Congestion information from Egress to Ingress Nodes
in a DiffServ Domain (Informational)' per Joe's suggestion. 

Now isn't there something puzzling in keeping 'Encoding and Transport of
(Pre-)Congestion Information from the Domain Egress to the Ingress' as a
Proposed Standard? Proposed Standard seems to suggest that the PCN WG
will be defining protocol mechanisms for this, which is not obviously
the case. What if this relies on other protocols that may be running
between the boundary nodes in different scenarios (e.g. NSIS QoS NSLP,
RSVP, SDP in SIP)? In that case such a document, if at all needed, would
probably have to be just a BCP.

Benny

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, February 05, 2007 10:33 AM
To: [email-masked]
Subject: [PCN] PCN Charter proposal version 4

Hi,

Cheers

Magnus

----

Chair(s):
    tbd

Transport Area Advisor:

Mailing Lists:

    (2) a specification of conditions under which interior nodes
generate
        (pre-)congestion information

    (6) ingress node control mechanisms for flow admission or
termination,
        based on aggregated (pre-)congestion information

The initial scope of the PCN WG is restricted by the following
assumptions:

    (C) the number of flows across any potential aggregation bottleneck
        is sufficiently large for stateless, statistical mechanisms to
be
        effective

    (D) flows may have different precedence, but the applicability
        of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP,
etc.)
        is out of scope

Goals and Milestones:

-- 

Magnus Westerlund

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 6 Feb 2007 11:00:58 +0100

Just a few editorial comments (marked ^^).

Regards, Ruediger

[snip]

|The Congestion and Pre-Congestion Notification (PCN) working group 
|develops mechanisms to protect the quality-of-service of established 
|flows within a DiffServ domain when congestion is imminent or 
|existing. 
|These mechanisms operate at the domain boundary, based on aggregated 
|congestion and pre-congestion information from within the domain. The 
|focus of the WG is on developing standards for the marking behavior of 
|the interior nodes and the encoding and transport of the congestion 
|information.                        ^^^

[snip]

|Mar 2008   Flow Admission and Termination within a DiffServ
|       ^   Domain (Informational)
|
|Mar 2008   (Pre-)Congestion Detection within a DiffServ Domain
|       ^    (Proposed Standard)
|

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 6 Feb 2007 11:03:05 +0100

Hi 

I agree with Benny's suggestion that we should not make the  
'Encoding and Transport of (Pre-)Congestion Information from the Domain 
Egress to the Ingress' as a Proposed Standard.
BCP is okay with me!

Best Regards,
Georgios

> From: Rodrig, Benny (Benny) [mailto:[email-masked]] 
> Sent: maandag 5 februari 2007 19:56
> To: Magnus Westerlund; [email-masked]
> Subject: RE: [PCN] PCN Charter proposal version 4
> 
> I think it was good to add to the milestones the 
> 'Requirements for Signaling of (Pre-)Congestion information 
> (Informational)' per Joe's suggestion. 
> 
> Now isn't there something puzzling in keeping 'Encoding and 
> Transport of (Pre-)Congestion Information from the Domain 
> Egress to the Ingress' as a Proposed Standard? Proposed 
> Standard seems to suggest that the PCN WG will be defining 
> protocol mechanisms for this, which is not obviously the 
> case. What if this relies on other protocols that may be 
> running between the boundary nodes in different scenarios 
> (e.g. NSIS QoS NSLP, RSVP, SDP in SIP)? In that case such a 
> document, if at all needed, would probably have to be just a BCP.
> 
> Benny
> 
> 
> modifications in the beginning to try to be more explicit 
> about the decomposition. Then I also incorporated some of 
> Jozef's comments.
> 
> Cheers
> 
> Magnus
> 
> ----
> 
> The Congestion and Pre-Congestion Notification (PCN) working 
> group develops mechanisms to protect the quality-of-service 
> of established flows within a DiffServ domain when congestion 
> is imminent or existing. 
> These mechanisms operate at the domain boundary, based on 
> aggregated congestion and pre-congestion information from 
> within the domain. The focus of the WG is on developing 
> standards for the marking behavior of the interior nodes and 
> the encoding transport of the congestion information. The 
> transport and encoding of the congestion information is 
> decompositioned into several components. The forward flow 
> path to the domain boundary, the metering of the congestion 
> situation at the boundary, and the transport of the data to 
> the controlling peer. This decomposition is done to allow for 
> future extensibility by defining additional variants of the 
> components (with the exception of the first one). Reaction 
> mechanisms at the boundary consist of flow admission and flow 
> termination. Although designed to work together, flow 
> admission and flow termination are independent mechanisms, 
> and the use of one does not require or prevent the use of the 
> other. In consultation with the AD, the WG may produce a 
> small number of informational documents that describe how 
> specific quality-of-service policies for a domain can be 
> The PCN WG will specify the following components to protect 
> the quality-of-service of flows within a DiffServ domain:
> 
> The WG focuses on the overall architecture, and specifically 
> on the marking behavior and encoding and transport mechanisms 
> needed to realize it. Standards-track protocols and 
> mechanisms are only developed where necessary for 
> interoperability. For other components of the architecture, 
> the WG may document examples or provide recommended solutions 
> in informational documents. The architecture document will be 
> comprehensive, and include security, manageability and 
> operational considerations. If this WG requires extensions or 
> modifications to protocols that are products of other WGs, it 
> may motivate their need and describe requirements in 
> informational documents; design of such extensions and 
> modifications will take place in the appropriate WGs.
> 
> 
> After completion of the initial phase, the PCN WG may 
> re-charter to develop solutions for scenarios where some of 
> these restrictions are not in place. It may also re-charter 
> to consider applying the PCN mechanisms to additional 
> deployment scenarios (operation over concatenated DiffServ 
> domains, PCN-aware application mechanisms, etc.). The WG may 
> also consider to investigate additional response mechanisms 
> that act on (pre-)congestion information. One example could 
> be flow-rate adaptation (rather than flow 
> admission/termination) during times of congestion. The 
> details of these work items are outside the scope of the 
> initial phase; but the WG may consider their requirements to 
> design components that are sufficiently general to support 
> such extensions in the future.
> 
> 
> Goals and Milestones:
>

---

From: <[email-masked]>
Date: Tue, 6 Feb 2007 12:54:31 -0000

The encoding has to be STD, I believe 
The transport protocol - have given my views earlier

> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 06 February 2007 10:03
> To: 'Rodrig, Benny (Benny)'; 'Magnus Westerlund'; [email-masked]

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 6 Feb 2007 13:28:45 -0000

hi, 

> From: [email-masked] [mailto:[email-masked]] 
> 

Now I'm very confused. If we are talking about the communication
between edge/boundary nodes (e.g. in the current proposal this
is mainly egress --> ingress notifications IIRC), then I can't 
see why the encoding would have one status and the transport 
another.

Furthermore, since we are talking about protocols between nodes
(albeit within the same domain - but then the interior-->edge
is also intra-domain) then this would seem to be an interoperability
issue for which the standards track is in principle appropriate.

However, the charter also contains the text
> > > If this WG requires extensions or 
> > > modifications to protocols that are products of other WGs, it may 
> > > motivate their need and describe requirements in informational 
> > > documents; design of such extensions and modifications will take 
> > > place in the appropriate WGs.

which seems exactly correct. In other words, if it turns out that
rsvp/nsis/sip/whatever extensions are needed, those extensions should
not be PCN products; an appropriate PCN product would be an
informational
which stated what functionality an extension would need. Only if PCN
developed a *new* protocol for edge-edge communication (e.g.
egress-ingress
notifications) would a standards track document for the Nov 2008
milestone
be appropriate, but that would seem a surprising state of affairs.

?

robert h.

> 'Encoding 
> > and Transport of (Pre-)Congestion Information from the
> Domain
> 'Requirements for 
> > > Signaling of (Pre-)Congestion information from Egress to Ingress 
> > > Nodes in a DiffServ Domain (Informational)' per Joe's suggestion.
> > >
> Egress to 
> > > the Ingress' as a Proposed Standard? Proposed Standard seems to 
> > > suggest that the PCN WG will be defining protocol mechanisms for 
> > > this, which is not obviously the case. What if this 
> relies on other 
> > > protocols that may be running between the boundary nodes in 
> > > different scenarios (e.g. NSIS QoS NSLP, RSVP, SDP in 
> SIP)? In that 
> > > case such a document, if at all needed, would probably have to be 
> > > just a BCP.
> > >
> > > Benny
> > >
> > >
> about the 
> aggregated 
> > > congestion and pre-congestion information from within the domain. 
> > > The focus of the WG is on developing standards for the marking 
> > > behavior of the interior nodes and the encoding transport of the 
> > > congestion information. The transport and encoding of the 
> congestion 
> > > information is decompositioned into several components. 
> The forward 
> > > flow path to the domain boundary, the metering of the congestion 
> > > situation at the boundary, and the transport of the data to the 
> > > controlling peer. This decomposition is done to allow for future 
> > > extensibility by defining additional variants of the components 
> > > (with the exception of the first one). Reaction mechanisms at the 
> > > boundary consist of flow admission and flow termination. Although 
> > > designed to work together, flow admission and flow 
> termination are 
> > > independent mechanisms, and the use of one does not require or 
> > > prevent the use of the other. In consultation with the AD, the WG 
> > > may produce a small number of informational documents 
> that describe 
> > > how specific quality-of-service policies for a domain can be 
> > > marking behavior and encoding and transport mechanisms needed to 
> > > realize it. Standards-track protocols and mechanisms are only 
> > > developed where necessary for interoperability. For other 
> components 
> > > of the architecture, the WG may document examples or provide 
> > > recommended solutions in informational documents. The 
> architecture 
> > > document will be comprehensive, and include security, 
> manageability 
> > > and operational considerations. If this WG requires extensions or 
> > > modifications to protocols that are products of other WGs, it may 
> > > motivate their need and describe requirements in informational 
> > > documents; design of such extensions and modifications will take 
> > > place in the appropriate WGs.
> > >
> > >
> > >         is sufficiently large for stateless, statistical 
> mechanisms 
> > > to be
> > >         effective
> > >
> re-charter to 
> > > develop solutions for scenarios where some of these 
> restrictions are 
> > > not in place. It may also re-charter to consider applying the PCN 
> > > mechanisms to additional deployment scenarios (operation over 
> > > concatenated DiffServ domains, PCN-aware application mechanisms, 
> > > etc.). The WG may also consider to investigate additional 
> response 
> > > mechanisms that act on (pre-)congestion information. One example 
> > > could be flow-rate adaptation (rather than flow
> > > admission/termination) during times of congestion. The details of 
> > > these work items are outside the scope of the initial 
> phase; but the 
> > > WG may consider their requirements to design components that are

---

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Tue, 6 Feb 2007 09:31:11 -0500

Indeed encoding & transport between domain boundary nodes will be STD
but likely by other WGs. If the Nov 2008 milestone stays in the PCN
charter in addition to the respective informational requirements doc,
then it will probably describe how to use those mechanisms specified by
the other WGs. Perhaps the wording 'encoding and transport' better be
replaced with the same language as in the requirements doc milestone,
hence:
- Nov 2008  Signalling of (Pre-)Congestion information from Egress to
Ingress Nodes in a DiffServ Domain (BCP)

Benny

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]] 
Sent: Tuesday, February 06, 2007 8:29 AM
To: [email-masked]; [email-masked]
Subject: RE: [PCN] PCN Charter proposal version 4

hi, 

> The transport protocol - have given my views earlier

Now I'm very confused. If we are talking about the communication between
edge/boundary nodes (e.g. in the current proposal this is mainly egress
--> ingress notifications IIRC), then I can't see why the encoding would
have one status and the transport another.

Furthermore, since we are talking about protocols between nodes (albeit
within the same domain - but then the interior-->edge is also
intra-domain) then this would seem to be an interoperability issue for
which the standards track is in principle appropriate.

> > > If this WG requires extensions or modifications to protocols that 
> > > are products of other WGs, it may motivate their need and describe

> > > requirements in informational documents; design of such extensions

> > > and modifications will take place in the appropriate WGs.

which seems exactly correct. In other words, if it turns out that
rsvp/nsis/sip/whatever extensions are needed, those extensions should
not be PCN products; an appropriate PCN product would be an
informational which stated what functionality an extension would need.
Only if PCN developed a *new* protocol for edge-edge communication (e.g.
egress-ingress
notifications) would a standards track document for the Nov 2008
milestone be appropriate, but that would seem a surprising state of
affairs.

?

robert h.

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 6 Feb 2007 10:31:14 -0500

I believe that the encoding of PCN information in the IP header that
interior nodes will perform needs to be standardized. 

The signaling or transport of PCN information from egress to ingress
nodes should be written as requirements (informational) so that
signaling protocols such as RSVP, NSIS and possibly others can be
extended to convey PCN information between boarder nodes. PCN WG will
not work on any extensions to signaling protocols.

Regards, Joe
QoS & Network Architecture
Telephone: 613-763-6098 (ESN 393-6098)
Email: [email-masked]
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: February 6, 2007 7:55 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [PCN] PCN Charter proposal version 4

> > mechanisms to be

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 6 Feb 2007 16:36:11 +0100

Hi Joe

Okay, then we actually agree! Informational for the 
PCN information from egress to ingress nodes is okay for me!

Best regards,
Georgios

> From: Jozef Babiarz [mailto:[email-masked]] 
> Sent: dinsdag 6 februari 2007 16:31
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> I believe that the encoding of PCN information in the IP 
> header that interior nodes will perform needs to be standardized. 
> 
> The signaling or transport of PCN information from egress to 
> ingress nodes should be written as requirements 
> (informational) so that signaling protocols such as RSVP, 
> NSIS and possibly others can be extended to convey PCN 
> information between boarder nodes. PCN WG will not work on 
> any extensions to signaling protocols.
> 
>     
> Regards, Joe

---

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Tue, 6 Feb 2007 10:38:48 -0500

Hi Joe,

That is my understanding as well. It is my understanding also that the
PCN WG might explicitly send a liason to relevant WGs to request
development of appropriate signaling extensions. 

Anna 

> Sent: Tuesday, February 06, 2007 10:31 AM

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 6 Feb 2007 10:47:36 -0500

Hi Anna,
I would support that.

Regards, Joe

-----Original Message-----
From: Anna Charny (acharny) [mailto:[email-masked]] 
Sent: February 6, 2007 10:39 AM
To: Babiarz, Jozef (CAR:0S03); [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [PCN] PCN Charter proposal version 4

Hi Joe,

Anna

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 07 Feb 2007 22:04:13 +0100

> not work on any extensions to signaling protocols.

Yes, this is a good summary. However, there will still be need for a 
standard tracks document that says which pieces that goes together in 
which way. Thus Informational or BCP does not seem appropriate. Thus, me 
and Lars intends to keep this milestone for the moment to be a standard 
track document.

Cheers

Magnus Westerlund

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 7 Feb 2007 17:57:20 -0500

>track document.

My thinking was that we only standardized the minimum staff that is
needed in the interor nodes and boundary edge nodes for
interoperability. In my view the PCN WG would not standardize how PCN
will be used in different deployment models. How the pieces go together
and how they would be used in different deployment models would be done
as Informational RFCs. I was thinking of following the DiffServ WG
approach of only standardizing mechnisims or protocols and leave it to
informational documents for different ways they can be used.
  
Regards, Joe
-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: February 7, 2007 4:04 PM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [PCN] PCN Charter proposal version 4

Cheers

Magnus Westerlund