Subject: [PCN] 3rd charter text update

From: Lars Eggert <[email-masked]>
Date: Fri, 2 Feb 2007 10:25:04 +0200

Hi,

attached is another charter text update. I think this is  
significantly more clear that previous iterations and can be  
submitted to the IESG and IAB for informal discussion.

Lars

---

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. 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, egress and ingress nodes of the domain

    (4) 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:

Jul 2007   Flow Admission and Termination Architecture
            (Informational)

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

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

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

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

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

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

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

---

From: Lars Westberg <[email-masked]>
Date: Fri, 02 Feb 2007 10:12:11 +0100

In some deplyment scenarios, other methods of adjusting the traffic 
volume are used. therefore, I see a need for separation of "cornerstone" 
RFC from RFC that should be optional.

Will the PCN working group, require an implementation of all RFC to be 
compliant to PCN ?

If not, what is the minimum set ?

regards Lasse
Lars Eggert wrote:

>------------------------------------------------------------------------
>

---

From: Lars Eggert <[email-masked]>
Date: Fri, 2 Feb 2007 11:29:11 +0200

On 2007-2-2, at 11:12, ext Lars Westberg wrote:
> volume are used. therefore, I see a need for separation of  
> "cornerstone" RFC from RFC that should be optional.
>
> Will the PCN working group, require an implementation of all RFC to  
> be compliant to PCN ?
>

Up to the architecture document to describe.

Lars

---

From: Lars Westberg <[email-masked]>
Date: Fri, 02 Feb 2007 10:33:42 +0100

yes, that's what I am worried about.

Can't we add a small text into the charter so we do not required a 
full-fledge Diff.serv edge functionality in the boundary nodes ???

regards Lasse

---

From: Lars Eggert <[email-masked]>
Date: Fri, 2 Feb 2007 11:47:15 +0200

> full-fledge Diff.serv edge functionality in the boundary nodes ???

I don't see how we can, because the goal is to PCN-enable a DiffServ  
region, which oviously requires the boundary to implement the DS  
functionality?

Lars

---

From: Lars Westberg <[email-masked]>
Date: Fri, 02 Feb 2007 10:54:33 +0100

When was that decided ?  on the BoF or ????

What I am considering is mainly a reduced set of functionality on the 
PCN-architecture.

Do we need to start-up for a new working group ?

regards Lasse

---

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Fri, 2 Feb 2007 09:31:30 -0500

I agree with Lars (Eggert) - this does seem to me that this issue
belongs to the architecture document.  The document should clearly
explain which functionality is minimally required.  If it happens to be
less that "full fledge" it should be spelled out clearly.  
 
I think the wording of the latest charter text certainly does not
prevent at all at the moment specifying a subset functionality
necessary. 
 
Anna 

________________________________

	From: Lars Westberg [mailto:[email-masked]] 
	Sent: Friday, February 02, 2007 4:55 AM
	To: Lars Eggert
	Cc: [email-masked]
	Subject: Re: [PCN] 3rd charter text update

	What I am considering is mainly a reduced set of functionality
on the PCN-architecture.

	regards Lasse
	
	Lars Eggert wrote:

		> full-fledge Diff.serv edge functionality in the
boundary nodes ???
		
		I don't see how we can, because the goal is to
PCN-enable a DiffServ 
		region, which oviously requires the boundary to
implement the DS 
		functionality?
		
		Lars

---

From: Lars Westberg <[email-masked]>
Date: Fri, 02 Feb 2007 16:06:10 +0100

ok, that's good. I had some problem to interprete the statement from LarsE.
So, it means that we can have disucssion this scenario as well in the 
working group.

regards Lasse

Anna Charny (acharny) wrote:

> explain which functionality is minimally required.  If it happens to 
> be less that "full fledge" it should be spelled out clearly. 
>  
> prevent at all at the moment specifying a subset functionality necessary.
>  
> Anna
>
>     What I am considering is mainly a reduced set of functionality on
>     the PCN-architecture.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 02 Feb 2007 16:29:36 +0100

> prevent at all at the moment specifying a subset functionality

I think it is important we do agree on that there is a possible 
decomposition in the PCN architecture between the forward path where 
pre-congestion marking happens, and the metering at the egress, and how 
one transports that information. Explicitly allowing that decomposition 
seems to me to be a requirement for allowing PCN to work with some of 
the other deployment scenarios, such as MGW at the edge nodes as Lars 
Westberg proposed, or the application aware scenarios that is also 
proposed. Otherwise they might be stuck with a lot of functionality that 
is not needed from the int-serv/diff-serv deployment we are taking on as 
first step.

Looking at the future plan section of the charter I think that covers 
this a bit insufficiently. It talks a lot of removing the restrictions. 
However changing the post metering transport and encoding would allow 
PCN to be used in other deployments and is a possible way. Thus I would 
like to clarify this somehow. However do note that I don't propose that 
any work should happen in these direction within the proposed WG 
initially. Only that we consider this and allow in the architecture for 
such development in the future.

Agreement or disagreement?

Cheers

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

---

From: Lars Westberg <[email-masked]>
Date: Fri, 02 Feb 2007 16:59:09 +0100

I agree

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 2 Feb 2007 17:03:21 +0100

Hi Magnus

I agree with your proposal!

Best Regards,
Georgios

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: vrijdag 2 februari 2007 16:30
> To: Anna Charny (acharny)
> Cc: [email-masked]; Lars Westberg
> I think it is important we do agree on that there is a 
> possible decomposition in the PCN architecture between the 
> forward path where pre-congestion marking happens, and the 
> metering at the egress, and how one transports that 
> information. Explicitly allowing that decomposition seems to 
> me to be a requirement for allowing PCN to work with some of 
> the other deployment scenarios, such as MGW at the edge nodes 
> as Lars Westberg proposed, or the application aware scenarios 
> that is also proposed. Otherwise they might be stuck with a 
> lot of functionality that is not needed from the 
> int-serv/diff-serv deployment we are taking on as first step.
> 
> Looking at the future plan section of the charter I think 
> that covers this a bit insufficiently. It talks a lot of 
> removing the restrictions. 
> However changing the post metering transport and encoding 
> would allow PCN to be used in other deployments and is a 
> possible way. Thus I would like to clarify this somehow. 
> However do note that I don't propose that any work should 
> happen in these direction within the proposed WG initially. 
> Only that we consider this and allow in the architecture for

---

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Fri, 2 Feb 2007 11:51:18 -0500

Hi Magnus,

I do agree that "there is a possible decomposition in the PCN
architecture between the forward path where pre-congestion marking
happens, and the metering at the egress, and how one transports that
information."

However, I want to point out that there is a danger in interpreting the
above to imply that one can define markings and edge reactions
completely independently of each other. That would not be true. For
example, an edge reaction designed to work with excess-rate marking is
unlikely to work with "CL-style admission marking" which marks *all*
packets with probability 1 once a certain traffic level has been
reached.  

As a result, interoperaility considerations may constrain what
combintions of marking and edge behavior pairs end up being defined.

I do think that the current wording of the charter allows the WG to
consider requirements of other deployment scenarios and extensions to
the initial work scope.  In fact it explicitly says that the WG may
"consider their requirements to design components that are sufficiently
general to support such extensions in the future".  These consideratoion
may (and probably should)limit the choices made in the first pahse of
the work.

My personal opinion is that the current text of the charter is very
good. It provides the scope that seems realistic to address within the
set timetable, and yet is flexible enough to allow the WG to be aware of
more general requirements.

Anna 
> Sent: Friday, February 02, 2007 10:30 AM
> Cc: Lars Westberg; Lars Eggert; [email-masked]

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 2 Feb 2007 18:09:06 +0100

Hi Anna

In my opinion it will help to clarify in the PCN charter text 
that "there is a possible decomposition in the PCN 
architecture between the forward path where pre-congestion 
marking happens, and the metering at the egress, and how one 
transports that information."

I think that your concerns stated in the second paragraph of your e-mail
can be addressed in the "Flow Admission and Termination Architecture" draft.

Best regards,
Georgios

> From: Anna Charny (acharny) [mailto:[email-masked]] 
> Sent: vrijdag 2 februari 2007 17:51
> To: Magnus Westerlund
> Subject: RE: [PCN] 3rd charter text update
> 
> Hi Magnus,
> 
> architecture between the forward path where pre-congestion 
> marking happens, and the metering at the egress, and how one 
> transports that information."
> 
> However, I want to point out that there is a danger in 
> interpreting the above to imply that one can define markings 
> and edge reactions completely independently of each other. 
> That would not be true. For example, an edge reaction 
> designed to work with excess-rate marking is unlikely to work 
> with "CL-style admission marking" which marks *all* packets 
> with probability 1 once a certain traffic level has been reached.  
> 
> As a result, interoperaility considerations may constrain 
> what combintions of marking and edge behavior pairs end up 
> being defined.
> 
> I do think that the current wording of the charter allows the 
> WG to consider requirements of other deployment scenarios and 
> extensions to the initial work scope.  In fact it explicitly 
> says that the WG may "consider their requirements to design 
> components that are sufficiently general to support such 
> extensions in the future".  These consideratoion may (and 
> probably should)limit the choices made in the first pahse of the work.
> 
> My personal opinion is that the current text of the charter 
> is very good. It provides the scope that seems realistic to 
> address within the set timetable, and yet is flexible enough 
> to allow the WG to be aware of more general requirements.
> 
> Anna 
> > pre-congestion marking happens, and the metering at the egress, and 
> > how one transports that information. Explicitly allowing that 
> > decomposition seems to me to be a requirement for allowing 
> PCN to work 
> > with some of the other deployment scenarios, such as MGW at 
> the edge 
> > nodes as Lars Westberg proposed, or the application aware scenarios 
> > that is also proposed. Otherwise they might be stuck with a lot of 
> > functionality that is not needed from the int-serv/diff-serv 
> > deployment we are taking on as first step.
> > 
> that covers 
> would allow 
> > PCN to be used in other deployments and is a possible way. Thus I 
> > would like to clarify this somehow.
> > However do note that I don't propose that any work should happen in 
> > these direction within the proposed WG initially.
> > Only that we consider this and allow in the architecture for such 
> > development in the future.
> >

---

From: "Jozef Babiarz" <[email-masked]>
Date: Fri, 2 Feb 2007 14:51:12 -0500

I'm in full agreement with Magnus's suggestion in decomposition of the
PCN architecture between the forward path, where pre-congestion marking
happens, the monitoring of PCN marking at the egress, what information
is transports from egress to ingress node and what the ingress node does
with the received PCN information.

Regards, Joe
Telephone: 613-763-6098 (ESN 393-6098)
Email: [email-masked]

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: February 2, 2007 10:30 AM
To: Anna Charny (acharny)
Cc: [email-masked]; Lars Westberg
Subject: Re: [PCN] 3rd charter text update

> explain which functionality is minimally required.  If it happens to
be

first step.

Cheers

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Sat, 3 Feb 2007 11:34:22 +0200

> with the received PCN information.

I agree that it would be useful to bring this out more clearly. It  
has been an underlying assumption, but you are right that the text  
could state this more prominently.

Lars

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 4 Feb 2007 15:51:35 -0500

I think the charter wording is good. One suggestion is that we add to
the first sentence "inelastic"  ... established inelastic flows within
DiffServ ... so that it's clear PCN will not be used with elastic flows.

>Jul 2007   Flow Admission and Termination Architecture

Would like to suggest that we allow more time for the completion of the
above document as it is to be comprehensive, and include security,
manageability and operational considerations as well decomposition of
the PCN architecture. Suggest Nov. 2007.

>            (Pre-)Congestion Information within a DiffServ Domain

I'm OK.
>Nov 2007   Flow Admission and Termination within a DiffServ

Suggest that "Flow Admission and Termination within a DiffServ Domain"
be moved to Mar 2008. One meeting after the architecture. 

>            from within a DiffServ Domain to the Egress

The (Pre-)Congestion Detection within a DiffServ Domain and Encoding and
Transport of (Pre-)Congestion Information from within a DiffServ Domain
to the Egress should be combined into on document. 

Mar 2008    (Pre-)Congestion Detection and Encoding within a DiffServ
            Domain
            (Proposed Standard)

>	   from the Domain Egress to the Ingress

To reflect the charter "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 above deliverable should be change to:

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

>Mar 2008   Suggested Flow Admission and Termination Boundary Mechanisms

I believe that for interoperability, the WG will need to define and
agree on standardized behavior for ingress and egress nodes for reaction
to PCN information. Specific mechanisms should only be document as
examples. The above deliverable should be changed to:  

Mar 2008   Behavioral definition for Ingress and Egress Nodes
           for Flow Admission and Termination within a
           DiffServ Domain 
           (Proposed Standard)

Regards, Joe
-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: February 2, 2007 3:25 AM
To: [email-masked]
Subject: [PCN] 3rd charter text update

Hi,

Lars

---

Chair(s):
    tbd

Transport Area Advisor:

Mailing Lists:

Goals and Milestones:

---

From: <[email-masked]>
Date: Mon, 5 Feb 2007 11:40:37 -0000

The charter looks good.
I agree with joe's suggested wording & Goals changes. On the issue of
the timing of the milestones, I prefer the original timescales to joe's
changes but either are OK with me.

Where joe suggests
>            from Egress to Ingress Nodes in a DiffServ Domain
Note that there will probably be signalling mods also in the direction
ingress to egress. Suggest changing "from Egress to Ingress Nodes" to
"between boundary nodes"

Thanks
phil

> From: Jozef Babiarz [mailto:[email-masked]]
> Sent: 04 February 2007 20:52
> To: Lars Eggert; [email-masked]
> Subject: RE: [PCN] 3rd charter Goals and Milestones
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 5 Feb 2007 14:14:33 +0100

Hi all

I agree with  Joe's proposal except the last deliverable, that in my opinion

Best Regards,
Georgios

> Sent: zondag 4 februari 2007 21:52
> I think the charter wording is good. One suggestion is that 
> we add to the first sentence "inelastic"  ... established 
> inelastic flows within DiffServ ... so that it's clear PCN 
> will not be used with elastic flows.
> 
> Would like to suggest that we allow more time for the 
> completion of the above document as it is to be 
> comprehensive, and include security, manageability and 
> operational considerations as well decomposition of the PCN 
> architecture. Suggest Nov. 2007.
> 
> The (Pre-)Congestion Detection within a DiffServ Domain and 
> Encoding and Transport of (Pre-)Congestion Information from 
> within a DiffServ Domain to the Egress should be combined 
> into on document. 
> 
> To reflect the charter "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."
> I believe that for interoperability, the WG will need to 
> define and agree on standardized behavior for ingress and 
> egress nodes for reaction to PCN information. Specific 
> mechanisms should only be document as examples. The above 
> deliverable should be changed to:  
> 
> 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. 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:
> 
>     (2) a specification of conditions under which interior 
> nodes generate
> 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.
> 
> 
>         is sufficiently large for stateless, statistical 
> mechanisms to be
>         effective
> 
>         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:
>

---

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Mon, 5 Feb 2007 09:31:01 -0500

I agree with Phil's suggestion for the last deliverable.  I am happy
with Joe's proposals for the milestones, although I am also  OK with the
current ones.

Anna 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, February 05, 2007 6:41 AM
> To: [email-masked]; [email-masked]; [email-masked]
> I agree with joe's suggested wording & Goals changes. On the 
> issue of the timing of the milestones, I prefer the original 
> timescales to joe's changes but either are OK with me.
> 
> Where joe suggests
> Note that there will probably be signalling mods also in the 
> direction ingress to egress. Suggest changing "from Egress to 
> Ingress Nodes" to "between boundary nodes"
> 
> Thanks
> phil
> 
> we add to 
> modifications
> significantly 
> > more clear that previous iterations and can be submitted to 
> the IESG 
> > and IAB for informal discussion.
> > 
> > Lars
> > 
> > ---
> > 
> > domain. The focus of the WG is on developing standards for 
> the marking 
> > behavior of the interior nodes and the encoding transport of the 
> consist of 
> > flow admission and flow termination. Although designed to work 
> > together, flow admission and flow termination are independent 
> > documents; design of such extensions and modifications will 
> take place 
> > in the appropriate WGs.
> > 
> > 
> mechanisms to 
> WPS, MLPP, 
> > etc.)
> > mechanisms that act on (pre-)congestion information. One 
> example could 
> sufficiently 
> > general to support such extensions in the future.
> > 
> > 
> > Goals and Milestones:
> >

---

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

Hi,

I think it is reasonable to push out the dates a bit.

> Mar 2008    (Pre-)Congestion Detection and Encoding within a DiffServ

This I don't agree with. The reasons to separate them is to allow for a 
reasonable decomposition. By keeping the separated in two milestones we 
can better ensure that the extensibility for future usages of PCN will 
be available.

>            from Egress to Ingress Nodes in a DiffServ Domain

So you are assuming that PCN are going to require extensions in the 
protocols. You might be right. However I still think there will be need 
for a proposed standard document in this WG on how one uses that extension.

>            for Flow Admission and Termination within a

This is not obvious. As the adaptation between how one accomplish a 
particular act as the result of the received information may be local in 
a node. And in addition it may not be unclear on how to act on that 
information.

But this points to a possible weakness of the current charter that it 
doesn't talk about which QoS model we are talking about doing flow 
admission with in the first shot. We probably should clarify this.

Cheers

Magnus Westerlund

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 6 Feb 2007 10:54:53 +0100

Magnus,

then what's a good way to proceed? The current drafts 
propose the CL QoS model. The PCN mechanism defined so 
far is designed to avoid packet loss. I like both, CL 
and the idea to react before packet loss occurs, at 
least with regard to admitted traffic.

Should PCN select one QoS model as an example and define 
how to standardise application of PCN for other QoS 
models? What to do if we can't reach consesus on one?
As an alternative, mechanisms for several QoS 
models could be standardised immediately. That doesn't 
sound tempting to me. On the other side, it would 
preferable if the signaling between boundary nodes is 
able to support different QoS models for which PCN 
is applied. A discussion on "signaling" supporting 
different "QoS models" is delaying progress of the NSIS 
WG since a couple of months now. We should make sure 
that PCN isn't running into similar problems. 

Regards,

Ruediger

|>> Mar 2008   Suggested Flow Admission and Termination Boundary Mechanisms
|>>            (Informational)
|> 
|> I believe that for interoperability, the WG will need to define and
|> agree on standardized behavior for ingress and egress nodes for reaction
|> to PCN information. Specific mechanisms should only be document as
|> examples. The above deliverable should be changed to:  
|> 
|> Mar 2008   Behavioral definition for Ingress and Egress Nodes
|>            for Flow Admission and Termination within a
|>            DiffServ Domain 
|>            (Proposed Standard)
|> 
|> 
|
|This is not obvious. As the adaptation between how one accomplish a 
|particular act as the result of the received information may 
|be local in a node. And in addition it may not be unclear on how to act on that 
|information.
|
|But this points to a possible weakness of the current charter that it 
|doesn't talk about which QoS model we are talking about doing flow 
|admission with in the first shot. We probably should clarify this.
|
|Cheers
|
|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: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Feb 2007 03:49:17 +0100

> least with regard to admitted traffic.

With the current charter it would be up to the WG to decide this.

> that PCN isn't running into similar problems. 

I agree that the WG should focus on a single or very few models.
In regards to the signalling. My understanding is that for certain 
usages and certain QoS models the signalling will look radically 
different. Thus the signalling should be developed for the model(s) 
chosen to work on for now. If you really like to lock down this in the 
charter you better get the discussion going. I am not convinced that 
this is necessary.

Cheers

Magnus Westerlund

---

From: Tina TSOU <[email-masked]>
Date: Fri, 16 Feb 2007 11:24:51 +0800

----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Geib, Ruediger" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 15, 2007 10:49 AM
Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model

> Geib, Ruediger skrev:
>> Magnus,
>>
>> then what's a good way to proceed? The current drafts propose the CL QoS 
>> model. The PCN mechanism defined so far is designed to avoid packet loss. 
>> I like both, CL and the idea to react before packet loss occurs, at least 
>> with regard to admitted traffic.
>>
>
I think both are reachable before the target date, allowing a bit delay:)
>
>
>> Should PCN select one QoS model as an example and define how to 
>> standardise application of PCN for other QoS models? What to do if we 
>> can't reach consesus on one?
>> As an alternative, mechanisms for several QoS models could be 
>> standardised immediately. That doesn't sound tempting to me. On the other 
>> side, it would preferable if the signaling between boundary nodes is able 
>> to support different QoS models for which PCN is applied. A discussion on 
>> "signaling" supporting different "QoS models" is delaying progress of the 
>> NSIS WG since a couple of months now. We should make sure that PCN isn't 
>> running into similar problems.
>
> In regards to the signalling. My understanding is that for certain usages 
> and certain QoS models the signalling will look radically different. Thus 
> the signalling should be developed for the model(s) chosen to work on for 
> now. If you really like to lock down this in the charter you better get 
> the discussion going. I am not convinced that this is necessary.
On the assumption that we work on CL QoS model and the model "react before 
packet loss occurs", are we going to have two kinds of signaling at least? I 
think it could be discussed after the WG is created. And the charter is not 
excluded is enough by now.
> IETF Transport Area Director & TSVWG Chair

B. R.
Tina

---

From: Lars Westberg <[email-masked]>
Date: Fri, 16 Feb 2007 08:18:03 +0100

comments

Tina TSOU wrote:

>
> ----- Original Message ----- From: "Magnus Westerlund" 
> <[email-masked]>
>>> then what's a good way to proceed? The current drafts propose the CL 
>>> QoS model. The PCN mechanism defined so far is designed to avoid 
>>> packet loss. I like both, CL and the idea to react before packet 
>>> loss occurs, at least with regard to admitted traffic.
>>>
>>

 I think we need to have a better definition because controlled load is 
refers to Int.serv models. This solution is based on traffic measurement 
and this will give much less "guarantees" than a reservation based 
solution. One simple examples that the approach does not guaratee 
bandwidth for temporary "silent"  traffic sources. The best results is 
acheived for "constant-bit rate" sources.

>>> standardise application of PCN for other QoS models? What to do if 
>>> we can't reach consesus on one?
>>> standardised immediately. That doesn't sound tempting to me. On the 
>>> other side, it would preferable if the signaling between boundary 
>>> nodes is able to support different QoS models for which PCN is 
>>> applied. A discussion on "signaling" supporting different "QoS 
>>> models" is delaying progress of the NSIS WG since a couple of months 
>>> now. We should make sure that PCN isn't running into similar problems.
>>
>>
>> chosen to work on for now. If you really like to lock down this in 
>> the charter you better get the discussion going. I am not convinced 
>> that this is necessary.
>
> On the assumption that we work on CL QoS model and the model "react 
> before packet loss occurs", are we going to have two kinds of 
> signaling at least? I think it could be discussed after the WG is 
> created. And the charter is not excluded is enough by now.
>
>>
>> Cheers
>>
>> Magnus Westerlund
>>

---

From: Tina TSOU <[email-masked]>
Date: Fri, 16 Feb 2007 16:26:22 +0800

----- Original Message ----- 
From: "Lars Westberg" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: "Geib, Ruediger" <[email-masked]>; "Magnus Westerlund" 
<[email-masked]>; <[email-masked]>
Sent: Friday, February 16, 2007 3:18 PM
Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model

>>>> QoS model. The PCN mechanism defined so far is designed to avoid packet 
>>>> loss. I like both, CL and the idea to react before packet loss occurs, 
>>>> at least with regard to admitted traffic.
>>>>
>>>

I agree with you. And it seems that few ppl has interest at Int.serv in core 
network in North America.

>>>> other side, it would preferable if the signaling between boundary nodes 
>>>> is able to support different QoS models for which PCN is applied. A 
>>>> discussion on "signaling" supporting different "QoS models" is delaying 
>>>> progress of the NSIS WG since a couple of months now. We should make 
>>>> sure that PCN isn't running into similar problems.
>>>
>>>
>> before packet loss occurs", are we going to have two kinds of signaling 
>> at least? I think it could be discussed after the WG is created. And the 
>> charter is not excluded is enough by now.
>>
>>>
>>> Cheers
>>>
>>> Magnus Westerlund
>>>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 16 Feb 2007 09:29:31 +0100

Lars,

my take on PCN is that it exploits statistical multiplexing. CBR 
traffic could be present, but VBR traffic is preferable. So also 
on off sources should be tolerated. Simulation results should 
help the WG to decide on acceptable and not acceptable traffic 
sources.

Regards,

Ruediger 

|-----Original Message-----
|From: Lars Westberg [mailto:[email-masked]]
|Sent: Friday, February 16, 2007 8:18 AM
|To: Tina TSOU
|Cc: [email-masked]; Geib, Rüdiger
|Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model
|
|
|comments
|
|Tina TSOU wrote:
|
|>
|> ----- Original Message ----- From: "Magnus Westerlund" 
|> <[email-masked]>
|> To: "Geib, Ruediger" <[email-masked]>
|> Cc: <[email-masked]>
|> Sent: Thursday, February 15, 2007 10:49 AM
|> Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model
|>
|>
|>> Geib, Ruediger skrev:
|>>
|>>> Magnus,
|>>>
|>>> then what's a good way to proceed? The current drafts 
|propose the CL 
|>>> QoS model. The PCN mechanism defined so far is designed to avoid 
|>>> packet loss. I like both, CL and the idea to react before packet 
|>>> loss occurs, at least with regard to admitted traffic.
|>>>
|>>
|>> With the current charter it would be up to the WG to decide this.
|>
|> I think both are reachable before the target date, allowing 
|a bit delay:) 
|
| I think we need to have a better definition because 
|controlled load is 
|refers to Int.serv models. This solution is based on traffic 
|measurement 
|and this will give much less "guarantees" than a reservation based 
|solution. One simple examples that the approach does not guaratee 
|bandwidth for temporary "silent"  traffic sources. The best results is 
|acheived for "constant-bit rate" sources.
|
|>
|>>
|>>
|>>> Should PCN select one QoS model as an example and define how to 
|>>> standardise application of PCN for other QoS models? What to do if 
|>>> we can't reach consesus on one?
|>>> As an alternative, mechanisms for several QoS models could be 
|>>> standardised immediately. That doesn't sound tempting to 
|me. On the 
|>>> other side, it would preferable if the signaling between boundary 
|>>> nodes is able to support different QoS models for which PCN is 
|>>> applied. A discussion on "signaling" supporting different "QoS 
|>>> models" is delaying progress of the NSIS WG since a couple 
|of months 
|>>> now. We should make sure that PCN isn't running into 
|similar problems.
|>>
|>>
|>> I agree that the WG should focus on a single or very few models.
|>> In regards to the signalling. My understanding is that for certain 
|>> usages and certain QoS models the signalling will look radically 
|>> different. Thus the signalling should be developed for the model(s) 
|>> chosen to work on for now. If you really like to lock down this in 
|>> the charter you better get the discussion going. I am not convinced 
|>> that this is necessary.
|>
|> On the assumption that we work on CL QoS model and the model "react 
|> before packet loss occurs", are we going to have two kinds of 
|> signaling at least? I think it could be discussed after the WG is 
|> created. And the charter is not excluded is enough by now.
|>
|>>
|>> Cheers
|>>
|>> 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]
|>> 
|----------------------------------------------------------------------
|>
|>
|> B. R.
|> Tina
|>
|>>
|>>
|>> _______________________________________________
|>> PCN mailing list
|>> [email-masked]
|>> https://www1.ietf.org/mailman/listinfo/pcn 
|>
|>
|>
|> _______________________________________________
|> PCN mailing list
|> [email-masked]
|> https://www1.ietf.org/mailman/listinfo/pcn
|>
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: Tina TSOU <[email-masked]>
Date: Fri, 16 Feb 2007 17:50:48 +0800

Ruediger,
That makes sense. And at the time being, we don't have such simulation 
results by hand, is it more flexible that we leave it outside of charter? Or 
we could have an informal document to describe how CBR and VBR co-exist in 
PCN?

B. R.
Tina

----- Original Message ----- 
From: "Geib, Ruediger" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 16, 2007 4:29 PM
Subject: RE: [PCN] 3rd charter Goals and Milestones - QoS model

Lars,

Regards,

Ruediger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 16 Feb 2007 11:38:09 +0100

Tina,

after having sent my email it came to my mind that I should 
specify what I'm talking about with regard to a "QoS model". 
PCN aims on ensuring a low packet loss for DiffServ traffic. 
Selecting the CL model for the DiffServ section makes a lot 
of sense, because I think the task of PCN would be 
significantly harder if is to specify the performance 
resulting from PCN in terms of "Guaranteed Packet Loss 
Rates" within the DiffServ region.

Now the "QoS model supported" also relates to the service 
using PCN transport, i.e. the service supported by the per 
flow signaling protocol terminating at the PCN edge. I don't 
make assumptions on the QoS model of the "per flow section". 
I'd prefer PCN to focus on the CL QoS model for the PCN 
DiffServ domain initially. Once simultaions and operational 
experience allow to work on quantiyable DiffServ QoS models, 
PCN could do that too.

The simulations performed by Anna and Michael certainly make 
assumptions on the aggregated traffic and its statistical 
behaviour. To avoid repeated requests for their (and may be 
other) simulation results on measurement based admission 
control, some volunteer may put together references to 
documents which are helpful to understand PCN. Maybe as part 
of the architecture or requirements draft?

Regards,

Ruediger

|-----Original Message-----
|From: Tina TSOU [mailto:[email-masked]]
|Sent: Friday, February 16, 2007 10:51 AM
|To: [email-masked]; Geib, Rüdiger
|Cc: [email-masked]
|Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model
|
|
|Ruediger,
|That makes sense. And at the time being, we don't have such simulation 
|results by hand, is it more flexible that we leave it outside 
|of charter? Or 
|we could have an informal document to describe how CBR and VBR 
|co-exist in 
|PCN?
|
|B. R.
|Tina
|
|----- Original Message ----- 
|From: "Geib, Ruediger" <[email-masked]>
|To: <[email-masked]>
|Cc: <[email-masked]>
|Sent: Friday, February 16, 2007 4:29 PM
|Subject: RE: [PCN] 3rd charter Goals and Milestones - QoS model
|
|
|Lars,
|
|my take on PCN is that it exploits statistical multiplexing. CBR
|traffic could be present, but VBR traffic is preferable. So also
|on off sources should be tolerated. Simulation results should
|help the WG to decide on acceptable and not acceptable traffic
|sources.
|
|Regards,
|
|Ruediger
|
||-----Original Message-----
||From: Lars Westberg [mailto:[email-masked]]
||Sent: Friday, February 16, 2007 8:18 AM
||To: Tina TSOU
||Cc: [email-masked]; Geib, Rüdiger
||Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model
||
||
||comments
||
||Tina TSOU wrote:
||
||>
||> ----- Original Message ----- From: "Magnus Westerlund"
||> <[email-masked]>
||> To: "Geib, Ruediger" <[email-masked]>
||> Cc: <[email-masked]>
||> Sent: Thursday, February 15, 2007 10:49 AM
||> Subject: Re: [PCN] 3rd charter Goals and Milestones - QoS model
||>
||>
||>> Geib, Ruediger skrev:
||>>
||>>> Magnus,
||>>>
||>>> then what's a good way to proceed? The current drafts
||propose the CL
||>>> QoS model. The PCN mechanism defined so far is designed to avoid
||>>> packet loss. I like both, CL and the idea to react before packet
||>>> loss occurs, at least with regard to admitted traffic.
||>>>
||>>
||>> With the current charter it would be up to the WG to decide this.
||>
||> I think both are reachable before the target date, allowing
||a bit delay:)
||
|| I think we need to have a better definition because
||controlled load is
||refers to Int.serv models. This solution is based on traffic
||measurement
||and this will give much less "guarantees" than a reservation based
||solution. One simple examples that the approach does not guaratee
||bandwidth for temporary "silent"  traffic sources. The best results is
||acheived for "constant-bit rate" sources.
||
||>
||>>
||>>
||>>> Should PCN select one QoS model as an example and define how to
||>>> standardise application of PCN for other QoS models? What to do if
||>>> we can't reach consesus on one?
||>>> As an alternative, mechanisms for several QoS models could be
||>>> standardised immediately. That doesn't sound tempting to
||me. On the
||>>> other side, it would preferable if the signaling between boundary
||>>> nodes is able to support different QoS models for which PCN is
||>>> applied. A discussion on "signaling" supporting different "QoS
||>>> models" is delaying progress of the NSIS WG since a couple
||of months
||>>> now. We should make sure that PCN isn't running into
||similar problems.
||>>
||>>
||>> I agree that the WG should focus on a single or very few models.
||>> In regards to the signalling. My understanding is that for certain
||>> usages and certain QoS models the signalling will look radically
||>> different. Thus the signalling should be developed for the model(s)
||>> chosen to work on for now. If you really like to lock down this in
||>> the charter you better get the discussion going. I am not convinced
||>> that this is necessary.
||>
||> On the assumption that we work on CL QoS model and the model "react
||> before packet loss occurs", are we going to have two kinds of
||> signaling at least? I think it could be discussed after the WG is
||> created. And the charter is not excluded is enough by now.
||>
||>>
||>> Cheers
||>>
||>> 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]
||>>
||----------------------------------------------------------------------
||>
||>
||> B. R.
||> Tina
||>
||>>
||>>
||>> _______________________________________________
||>> PCN mailing list
||>> [email-masked]
||>> https://www1.ietf.org/mailman/listinfo/pcn
||>
||>
||>
||> _______________________________________________
||> PCN mailing list
||> [email-masked]
||> https://www1.ietf.org/mailman/listinfo/pcn
||>
||
||
||_______________________________________________
||PCN mailing list
[email-masked]
||https://www1.ietf.org/mailman/listinfo/pcn
||
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn 
|
|

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 27 Feb 2007 13:54:03 +0100

Hi Fred,

TCP or "unknown" Pseudo Wire traffic and PCN real time traffic 
will not share the same queues. Your proposal wants to suggest 
a common mechanism resulting in traffic passing one queue to 
be marked by a PCN/ECN codepoint? May be also the determination 
of the rate of congestion marked traffic between an ingress 
and egress edge could be shared. Parts of the feed back mechanism 
between egress and ingress edge may be agreed to. The control 
plane more likely differs, so does the interpretation and 
reaction on a congestion indication. 

Should the above be possible, a router could apply the same 
basic congestion indication and evaluation mechanisms for 
different traffic types. Queuing and the reaction on the 
congestion indication would remain traffic type specific.

Would this rough description point to the right direction?

Regards,

Ruediger

---------Text excerpt from a reply of Fred Baker to Pekka Savola---
# From: Fred Baker <fred at cisco.com>
# Date: Mon, 19 Feb 2007 08:27:30 -0800

I dunno, I think that horse is out of the barn. In the TCP arena, 
the XCP and RCP proposals and RFC 3168 could each be described in 
those terms, and the pre-congestion notification proposals on the 
table all encode congestion information in the IP packets, mostly 
in the ECN field. I'll agree that they should not attempt to 
insert things into the packet (add an option), but using space 
already set aside in the packet needs to be on the table.

I would like to see some crossover between the TCP/SCTP congestion 
control proposals and the real-time pre-congestion proposals. 
That's not a matter of declaring something out of scope as much as 
it is to encourage thoughtful (and not knee-jerk) consideration of 
whether and how the two types of needs can be met.

The drafts I know to be relevant (you'll note that some are in pwe) 
are:

http://tools.ietf.org/html/draft-babiarz-pcn-sip-cap
  "SIP Controlled Admission and Preemption", Jozef Babiarz, 16-Oct-06,
  <draft-babiarz-pcn-sip-cap-00.txt>

http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture
"An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission
Control over a DiffServ Region", Bob Briscoe, 25-Oct-06,
<draft-briscoe-tsvwg-cl-architecture-04.txt>

http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-phb
  "Pre-Congestion Notification marking", Bob Briscoe, 22-Oct-06,
  <draft-briscoe-tsvwg-cl-phb-03.txt>

http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp
  "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob
  Briscoe, 26-Oct-06, <draft-briscoe-tsvwg-re-ecn-tcp-03.txt>

http://tools.ietf.org/html/draft-chan-pcn-problem-statement
"Pre-Congestion Notification Problem Statement", Kwok Ho Chan, 25- Oct-06,
<draft-chan-pcn-problem-statement-01.txt>

http://tools.ietf.org/html/draft-davie-ecn-mpls
  "Explicit Congestion Marking in MPLS", Bruce Davie, 19-Oct-06,
  <draft-davie-ecn-mpls-01.txt>

http://tools.ietf.org/html/draft-ietf-pwe3-congestion-frmwk
  "Pseudowire Congestion Control Framework", Stewart Bryant, 2-Feb-07,
  <draft-ietf-pwe3-congestion-frmwk-00.txt>

http://tools.ietf.org/html/draft-rosen-pwe3-congestion
  "Pseudowire Congestion Control Framework", Eric Rosen, 19-Oct-06,
  <draft-rosen-pwe3-congestion-04.txt>

PCN at ietf.org

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Feb 2007 08:26:38 -0800

On Feb 27, 2007, at 4:54 AM, Geib, Ruediger wrote:
> TCP or "unknown" Pseudo Wire traffic and PCN real time traffic will  
> not share the same queues.

In the vast majority of the network today, they do in fact share the  
same queues, and I'm not sure I can say that this will change any  
time soon.

My concern is this. The equipment folks buy and install in networks  
doesn't come pre-configured with any complex policy. Cisco product  
has something called "AutoQoS" that will - when requested to -  
install a certain policy, but that policy is pretty limited.  
Generally speaking, the initial policy is "FIFO, Tall Drop", and  
anything else that needs to happen has to be configured.

So you can't assume that all interfaces in the Internet are  
configured in the same way. They will be configured in the way their  
network administration wants them configured, and anything different  
than default is likely to be something someone paid them to do and  
which they believe materially affects their network's ability to  
deliver that stated service.

I have attached two configurations for generic Cisco equipment. One  
is to deploy the classes specified in RFC 4594, which is the set of  
classes we believe are appropriate to an access link. The other is  
for the Core-facing links. Note that both are significantly more  
complex than are currently deployed by default.

You'll notice that ECN has to be turned on. Implication: in the  
general case it is not turned on. You are proposing that the ECN  
implementation differ by service class. If the service classes aren't  
uniformly configured, explain to me how this works?

> Your proposal wants to suggest a common mechanism resulting in  
> traffic passing one queue to be marked by a PCN/ECN codepoint?

I want one marking algorithm that can be applied to all traffic in  
the backbone and be interpreted by the edge device resulting in it  
doing the right thing. Note that the right thing differs by service  
class - a G.711 codec isn't going to send less data because someone  
in the network is signaling congestion, but TCP will, and that is a  
huge difference.