Subject: [PCN] charter text update

From: Lars Eggert <[email-masked]>
Date: Thu, 25 Jan 2007 09:23:02 +0200

(I thought I had sent this several days ago, but it apparently never  
made it to the list?)

Hi,

below is a modified version of the PCN charter posted to this list a  
while ago. I believe it reflects the consensus after the face-to-face  
and mailing list discussions in and after Montreal.

Compared to the earlier version, the major changes are:

	- removal of SIP, application-based and PW deployment scenarios
	- stronger language on assumptions and scope
	- refactored deliverables and milestones
	- name change (don't feel strongly about this)

Please send your comments to the list.

Lars

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

Flow Admission and Preemption (flap)
Chair(s):
    tbd

Description of Working Group:

The Flow Admission and Preemption (FLAP) working group develops flow  
admission and flow preemption mechanisms for deployment along the  
edge of a network domain that protect the quality-of-service that  
previously-admitted flows experience within the domain during times  
of congestion. These mechanisms act on aggregated congestion and pre- 
congestion signals from routers within the network domain and control  
the admission of new flows into the domain or preempt previously- 
admitted flows. Although designed to work together, flow admission  
and flow preemption are independent mechanisms, and the use of one  
does not require the use of the other.

The FLAP WG will specify the following components of an integrated  
flow admission and preemption mechanism:

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

    (2) conditions under which interior routers generate
        (pre-)congestion signals

    (3) encoding and transport of (pre-)congestion signals
        to the appropriate ingress routers of the network domain

    (4) edge router control mechanisms for flow admission and
        preemption based on aggregated (pre-)congestion information

The WG focuses on the overall architecture and specifically the  
signaling interfaces needed to realize it. Standards-track protocols  
are only developed when necessary for interoperability. When  
algorithms are not necessary for interoperability the WG may document  
examples or provide recommended solutions, however such work should  
not be done at the expense of normative specifications.

The initial scope of the FLAP WG is restricted in the following ways:

    (A) develop these components for a single DiffServ region,
        where all edge and interior routers are FLAP-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) aggregation occurs either on links or ingress/egress pairs;
        mechanisms must further define relevant limits

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

After completion of the initial phase, the FLAP WG may recharter to  
develop solutions for scenarios where some of these restrictions are  
not in place. It may also recharter to consider applying the FLAP  
mechanisms to additional deployment scenarios (operation over  
concatenated DiffServ regions, FLAP-aware application mechanisms,  
etc.). The WG may also consider to investigate additional response  
mechanisms that act on (pre-)congestion signals. One example could be  
flow-rate adaptation (rather than flow admission/preemption) during  
times of congestion. The details of these work items are outside the  
scope of the initial phase; but the WG may want to

However in the initial scope this mechanism is out-of-scope with the  
exception that the developed solution should not, if possible,  
prevent a future evolution to support this.

Goals and Milestones:

Jul 2007   Flow Admission and Preemption Architecture
            (Informational)

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

Nov 2007   Flow Admission and Preemption within a DiffServ
            Region (Informational)

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

Mar 2008   Encoding and Transport of (Pre-)Congestion Signals
            within a DiffServ Region to Flow Egress (Proposed Standard)

Mar 2008   Transport from Flow Egress in a DiffServ Region of  
information
            (possibly aggregated) or Admission/Preemption Signals to
            DiffServ edge devices. (Proposed Standard)

Mar 2008   Suggested Flow Admission and Preemption Edge Mechanisms
            (Informational)

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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 25 Jan 2007 09:34:30 +0200

Copy/paste error corrected below.

On 2007-1-25, at 9:23, ext Lars Eggert wrote:
> The Flow Admission and Preemption (FLAP) working group develops  
> flow admission and flow preemption mechanisms for deployment along  
> the edge of a network domain that protect the quality-of-service  
> that previously-admitted flows experience within the domain during  
> times of congestion. These mechanisms act on aggregated congestion  
> and pre-congestion signals from routers within the network domain  
> and control the admission of new flows into the domain or preempt  
> previously-admitted flows. Although designed to work together, flow  
> admission and flow preemption are independent mechanisms, and the  
> use of one does not require the use of the other.
>
> signaling interfaces needed to realize it. Standards-track  
> protocols are only developed when necessary for interoperability.  
> When algorithms are not necessary for interoperability the WG may  
> document examples or provide recommended solutions, however such  
> work should not be done at the expense of normative specifications.
>
>
> develop solutions for scenarios where some of these restrictions  
> are not in place. It may also recharter to consider applying the  
> FLAP mechanisms to additional deployment scenarios (operation over  
> mechanisms that act on (pre-)congestion signals. One example could  
> be flow-rate adaptation (rather than flow admission/preemption)  
> during times of congestion. The details of these work items are  
> outside the scope of the initial phase; but the WG may want to

...consider their requirements during the design of the initial  
components.

> However in the initial scope this mechanism is out-of-scope with  
> the exception that the developed solution should not, if possible,

---

From: ken carlberg <[email-masked]>
Date: Thu, 25 Jan 2007 13:37:19 -0300

Lars,

I'd have a strong preference to keep the previous name, and to soften  
the use of the term Preemption in the charter.  if the IESG is  
consistent, some of the them will have a difficult time with the term  
preemption and will kick back the charter and ask that it be  
reworded.  Some in the IESG had a hard time with this subject (as  
well as some others) in the IEPREP group -- both in the past and most  
recently in the IETF mailing list concerning an attempted re- 
chartering effort for IEPREP.

A few months i brought up this topic on PCN and mentioned how under  
certain scenarios/circumstances, the use of preemption for VoIP is  
simply not allowed in certain countries.

http://www1.ietf.org/mail-archive/web/pcn/current/msg00023.html
http://www1.ietf.org/mail-archive/web/pcn/current/msg00037.html
http://www1.ietf.org/mail-archive/web/pcn/current/msg00046.html
http://www1.ietf.org/mail-archive/web/pcn/current/msg00053.html

Unfortunately, the subject of what is legal/regulated is not one that  
technical in nature, but it is something that should be considered by  
the group.  In my previous comments, I was trying to encourage the  
group to treat preemption as one of several (re)actions that can be  
advanced by the group.  I'd like to re-encourage this line of thought  
and text in the Charter.

regards,

-ken

ps, my apologies in not volunteering specific suggested text changes  
right now, but I'm preparing for a couple of days of travel (ugh).

On Jan 25, 2007, at 4:23 AM, Lars Eggert wrote:

> (I thought I had sent this several days ago, but it apparently  
> never made it to the list?)
>
> Hi,
>
> below is a modified version of the PCN charter posted to this list  
> a while ago. I believe it reflects the consensus after the face-to- 
> face and mailing list discussions in and after Montreal.
>
> ---------------------------------------------------------------------- 
> ----
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 25 Jan 2007 19:01:19 +0200

On 2007-1-25, at 18:37, ext ken carlberg wrote:
> I'd have a strong preference to keep the previous name

OK - the name change came about when the evolving charter was focused  
more on the admission and preemption mechanisms than it is now. I'm  
OK with reverting to the old name.

> , and to soften the use of the term Preemption in the charter.  if  
> the IESG is consistent, some of the them will have a difficult time  
> with the term preemption and will kick back the charter and ask  
> that it be reworded.  Some in the IESG had a hard time with this  
> subject (as well as some others) in the IEPREP group -- both in the  
> past and most recently in the IETF mailing list concerning an  
> attempted re-chartering effort for IEPREP.

It's not the term preemption, it is the concept of preemption  
especially in the context of emergency use. Which is why restriction  
(E) specifically declares this to be out-of-scope:

>>        of these mechanisms for emergency use (911, GETS, WPS,  
>> MLPP, etc.)
>>        is out of scope

> Unfortunately, the subject of what is legal/regulated is not one  
> that technical in nature, but it is something that should be  
> considered by the group.  In my previous comments, I was trying to  
> encourage the group to treat preemption as one of several (re) 
> actions that can be advanced by the group.  I'd like to re- 
> encourage this line of thought and text in the Charter.

I have little hope that this group would make any better progress on  
this issue than the other groups that are having a hard time with it.  
I also haven't seen strong consensus that emergency use was a stated  
goal.

Lars

---

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Thu, 25 Jan 2007 13:31:05 -0600

Lars,

I have several questions regarding the proposed new charter which may be
because I don't have a real good understanding of pre-congestion versus
actual congestion:

Why would we want to preempt existing real sessions prior to an actual
congestion?

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

By this I assume that we would not preempt or prevent these kinds of
emergency calls. What does it imply about preemption of ordinary calls
in favor of emergency calls?

As for the name, it did seem to me at least that the ability to
anticipate congestion and modify edge behavior is more palatable than
focusing on when congestion exists as implied by the FLAP name (Flow
Admission and Preemption (flap)).  Am I misinterpreting the impression
this would leave in peoples' minds?

Stuart Goldman
Alcatel-Lucent 
[email-masked]
602 493 8438

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: Thursday, January 25, 2007 12:23 AM
To: [email-masked]
Subject: [PCN] charter text update

Hi,

Lars

--

Goals and Milestones:

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 26 Jan 2007 09:23:07 +0100

Lars,

I support Ken's view. Making "Preemption" part of a new PCN WG name 
doesn't seem to be wise to me too. Setting such a sharp focus on 
preemption could easily result in drawing to much attention from 
people whose background is more "preemption" then PCN. 

I appreciate that you at least don't object to Ken's suggestion 
to this regard.  

Cheers, Rudiger

|-----Original Message-----
|From: ken carlberg [mailto:[email-masked]]
|Sent: Thursday, January 25, 2007 5:37 PM
|To: Lars Eggert
|Cc: [email-masked]
|Subject: Re: [PCN] charter text update
|
|
|Lars,
|
|I'd have a strong preference to keep the previous name, and to soften  
|the use of the term Preemption in the charter.  if the IESG is  
|consistent, some of the them will have a difficult time with the term  
|preemption and will kick back the charter and ask that it be  
|reworded.  Some in the IESG had a hard time with this subject (as  
|well as some others) in the IEPREP group -- both in the past and most  
|recently in the IETF mailing list concerning an attempted re- 
|chartering effort for IEPREP.
|
|A few months i brought up this topic on PCN and mentioned how under  
|certain scenarios/circumstances, the use of preemption for VoIP is  
|simply not allowed in certain countries.
|
|http://www1.ietf.org/mail-archive/web/pcn/current/msg00023.html
|http://www1.ietf.org/mail-archive/web/pcn/current/msg00037.html
|http://www1.ietf.org/mail-archive/web/pcn/current/msg00046.html
|http://www1.ietf.org/mail-archive/web/pcn/current/msg00053.html
|
|Unfortunately, the subject of what is legal/regulated is not one that  
|technical in nature, but it is something that should be considered by  
|the group.  In my previous comments, I was trying to encourage the  
|group to treat preemption as one of several (re)actions that can be  
|advanced by the group.  I'd like to re-encourage this line of thought  
|and text in the Charter.
|
|regards,
|
|-ken
|
|ps, my apologies in not volunteering specific suggested text changes  
|right now, but I'm preparing for a couple of days of travel (ugh).
|
|
|On Jan 25, 2007, at 4:23 AM, Lars Eggert wrote:
|
|> (I thought I had sent this several days ago, but it apparently  
|> never made it to the list?)
|>
|> Hi,
|>
|> below is a modified version of the PCN charter posted to this list  
|> a while ago. I believe it reflects the consensus after the face-to- 
|> face and mailing list discussions in and after Montreal.
|>
|> Compared to the earlier version, the major changes are:
|>
|> 	- removal of SIP, application-based and PW deployment scenarios
|> 	- stronger language on assumptions and scope
|> 	- refactored deliverables and milestones
|> 	- name change (don't feel strongly about this)
|>
|> Please send your comments to the list.
|>
|> Lars
|>
|> 
|---------------------------------------------------------------------- 
|> ----
|>
|> Flow Admission and Preemption (flap)
|> Chair(s):
|>    tbd
|>
|>
|> Description of Working Group:
|>
|> The Flow Admission and Preemption (FLAP) working group develops  
|> flow admission and flow preemption mechanisms for deployment along  
|> the edge of a network domain that protect the quality-of-service  
|> that previously-admitted flows experience within the domain during  
|> times of congestion. These mechanisms act on aggregated congestion  
|> and pre-congestion signals from routers within the network domain  
|> and control the admission of new flows into the domain or preempt  
|> previously-admitted flows. Although designed to work together, flow  
|> admission and flow preemption are independent mechanisms, and the  
|> use of one does not require the use of the other.
|>
|> The FLAP WG will specify the following components of an integrated  
|> flow admission and preemption mechanism:
|>
|>    (1) a general architecture for flow admission and preemption based
|>        on aggregated (pre-)congestion signals
|>
|>    (2) conditions under which interior routers generate
|>        (pre-)congestion signals
|>
|>    (3) encoding and transport of (pre-)congestion signals
|>        to the appropriate ingress routers of the network domain
|>
|>    (4) edge router control mechanisms for flow admission and
|>        preemption based on aggregated (pre-)congestion information
|>
|> The WG focuses on the overall architecture and specifically the  
|> signaling interfaces needed to realize it. Standards-track  
|> protocols are only developed when necessary for interoperability.  
|> When algorithms are not necessary for interoperability the WG may  
|> document examples or provide recommended solutions, however such  
|> work should not be done at the expense of normative specifications.
|>
|>
|> The initial scope of the FLAP WG is restricted in the following ways:
|>
|>    (A) develop these components for a single DiffServ region,
|>        where all edge and interior routers are FLAP-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) aggregation occurs either on links or ingress/egress pairs;
|>        mechanisms must further define relevant limits
|>
|>    (E) flows may have different precedence, but the applicability
|>        of these mechanisms for emergency use (911, GETS, WPS, MLPP,  
|> etc.)
|>        is out of scope
|>
|> After completion of the initial phase, the FLAP WG may recharter to  
|> develop solutions for scenarios where some of these restrictions  
|> are not in place. It may also recharter to consider applying the  
|> FLAP mechanisms to additional deployment scenarios (operation over  
|> concatenated DiffServ regions, FLAP-aware application mechanisms,  
|> etc.). The WG may also consider to investigate additional response  
|> mechanisms that act on (pre-)congestion signals. One example could  
|> be flow-rate adaptation (rather than flow admission/preemption)  
|> during times of congestion. The details of these work items are  
|> outside the scope of the initial phase; but the WG may want to
|>
|> However in the initial scope this mechanism is out-of-scope with  
|> the exception that the developed solution should not, if possible,  
|> prevent a future evolution to support this.
|>
|>
|> Goals and Milestones:
|>
|> Jul 2007   Flow Admission and Preemption Architecture
|>            (Informational)
|>
|> Jul 2007   Survey of Encoding and Transport Choices of
|>            (Pre-)Congestion Signals within a DiffServ Region
|>            (Informational)
|>
|> Nov 2007   Flow Admission and Preemption within a DiffServ
|>            Region (Informational)
|>
|> Nov 2007   (Pre-)Congestion Detection within a DiffServ Region
|>            (Proposed Standard)
|>
|> Mar 2008   Encoding and Transport of (Pre-)Congestion Signals
|>            within a DiffServ Region to Flow Egress (Proposed 
|Standard)
|>
|> Mar 2008   Transport from Flow Egress in a DiffServ Region of  
|> information
|>            (possibly aggregated) or Admission/Preemption Signals to
|>            DiffServ edge devices. (Proposed Standard)
|>
|> Mar 2008   Suggested Flow Admission and Preemption Edge Mechanisms
|>            (Informational)
|>
|>
|> _______________________________________________
|> 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: Lars Eggert <[email-masked]>
Date: Fri, 26 Jan 2007 11:16:59 +0200

Hi,

> Why would we want to preempt existing real sessions prior to an actual

First, "(pre-)congestion signals" expands to "pre-congestion and  
congestion signals." (I"m not too happy with this abbreviation, but  
using the expanded version everywhere is also not good -  
suggestions?) So maybe the edge reacts to pre-congestion signals with  
admission decisions, but to congestion signals (due to equipment  
failure, etc.) with preemption decisions.

But allowing an edge to preempt flows based on pre-congestion signals  
might also make sense, and I wouldn't want to exclude this option.  
Note that the edge policies will be described in Informational  
documents only, and maybe the WG wants to describe multiple edge  
policies that establish different behaviors.

> in favor of emergency calls?

This is supposed to express that whereas the edge is free to treat  
flows differently when it comes to deciding whether to admit or  
preempt some, use of the admission/preemption mechanisms for  
emergency use - with all the policy and legal implications that  
entails - is out of scope.

I'm open for suggestions on how to phrase this more clearly.

> this would leave in peoples' minds?

People have convinced me that sticking to the original PCN name is  
better. I will make that change in the next revision.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Jan 2007 11:17:41 +0200

> I appreciate that you at least don't object to Ken's suggestion

I'll change the name back to PCN in the next revision.

Lars

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 28 Jan 2007 21:00:21 -0500

Lars and all,

I also prefer PCN (Pre-Congestion Notification) as the name of the
workgroup.

Secondly, I also think that it is a good idea to soften the term
"preemption" or possibly do not use the preemption term as it has a
different function to what I believe the main focus of this work should
be.

Below is my attempt at rewording the PCN charter without changing the
scope. Hope it's helpful. I will send a separate email on adding
additional items to the scope.

The (Pre-)Congestion Notification (PCN) working group will develop
procedures and mechanisms for congestion control of inelastic flows to
protect the quality-of-service to previously-admitted traffic.
The WG will develop mechanism by which network node in DiffServ domain
can signal the onset of congestion and whereas nodes at the edges
monitor and react to the signaled (pre-)congestion information. The WG
will define procedure for admission control, the blocking of new flows
being added in to the network as the first step to congestion control
for inelastic traffic. As in some situation admission control may not be
sufficient, the WG will also define procedures for removal of excess
inelastic traffic should network nodes become congested. The removal of
excess traffic may consist of define methods for flow termination and/or
flow-rate adaptation.

The PCN WG will specify the following components of an integrated flow
admission and congestion relief mechanism:

    (1) a general architecture for congestion control of inelastic 
        flows through the use of (pre-)congestion signals

    (2) conditions under which network nodes generate
        (pre-)congestion signals

    (3) encoding and transport of (pre-)congestion signals in the
        network
        
    (4) edge nodes control procedures for flow admission and
        congestion relief based on (pre-)congestion information

The WG focuses on the overall architecture, (pre-)congestion marking
behavior and specifically the signaling interfaces needed to realize it.
Standards-track protocols are only developed when necessary for
interoperability. When algorithms are not necessary for interoperability
the WG may document examples or provide recommended solutions, however
such work should not be done at the expense of normative specifications.

The initial scope of the PCN WG is restricted in the following ways:

(A)	develop flow admission and removal of excess traffic mechanisms
    for a single DiffServ region, where all edge and interior
    routers are PCN-enabled and mutually trust each other

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

        etc.) is out of scope

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

However in the initial scope these mechanisms are out-of-scope with the
exception that the developed solution should not, if possible, prevent a
future evolution to support this.

Goals and Milestones:

Jul 2007   Congestion Control Architecture for Inelastic Flows
            (Informational)

Nov 2007   (Pre-)Congestion Detection and Encoding within a DiffServ
		Region
            (Proposed Standard)

Mar 2008   Behavioral definition for Ingress and Egress Network Nodes
           for Flow Admission and Removal of Excess Traffic within a
           DiffServ Region (Informational)

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

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

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 28 Jan 2007 21:47:03 -0500

Lars,
Do not understand why application aware (pre-)congestion is out of
scope? At the BOF in San Diego and on the PCN mailing list there was
support for it with people will to work on it. Specifically what I would
like to add to scope in the PCN charter is that "the PCN WG will define
requirements for conveying (pre-)congestion information from the
receiver to the sender and the actions that both the receiving host and
sending host should perform."

Regards, Joe

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: January 25, 2007 2:23 AM
To: [email-masked]
Subject: [PCN] charter text update

Hi,

Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 29 Jan 2007 11:07:54 +0200

Hi,

On 2007-1-29, at 4:47, ext Jozef Babiarz wrote:
> support for it with people will to work on it.

there was _some_ support for it, but there was also significant  
pushback against it, for example, from the SIP folks, who argued that  
the presented model for SIP-based deployment had significant issues.  
Consequently, at least from what I observed, we had rough consensus  
on not including it in the initial charter.

> Specifically what I would

The "host-to-host" deployment model is significantly different from  
the "edge-to-edge" one that the majority of the current discussion  
has focused on, with the latter one being somewhat simpler. Hence the  
approach is to deal with this first, while trying to ensure that the  
individual mechanisms (marking behavior, encoding, etc.) are  
sufficiently general to support both.

Thank you for the other suggested changes to the charter in your  
other email. I incorporated some of them into a revision of the  
charter text, which I'll email separately.

I didn't change "flow admission and preemption" to "congestion  
control", as that doesn't convey quite the same meaning and is also  
less specific. About the term "preemption", would people be OK with  
changing it to "termination?" (Preemption sounds like the flow can  
resume.) But this is a minor change IMO.

Lars

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 29 Jan 2007 10:37:23 +0100

Hi Lars

I agree with Jozef. In my opinion,
during the IETF in San Diego one could find a consensus to 
consider the application aware (pre-)congestion as being in 
the scope of this WG.
Furthermore, also in the e-mail discussions, I did not 
encounter a severe objection on introducing the application aware 
(pre-)congestion as being in the scope of this WG.

I would very much appreciate if you at least could include the following 
(modified proposal) of Jozef:
"the PCN WG will define requirements for 
conveying (pre-)congestion information from the receiver to 
the sender and the actions that both the receiving end host or gateway and 
sending end host or gateway should perform."

In addition to this I have another comment on the charter description.
Regarding the following paragraph:

"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 regions,
PCN-aware application mechanisms, etc.). The WG may also consider to
investigate additional response mechanisms that act on (pre-)congestion
signals. One example could be flow-rate adaptation (rather than flow
admission/preemption) during times of congestion. The details of these work
items are outside the scope of the initial phase; but the WG should consider
their requirements to design components that are sufficiently general to
support such extensions in the future."

First you mention:
"The WG may also consider to investigate additional response mechanisms that
act on (pre-)congestion signals. One example could be flow-rate adaptation
(rather than flow admission/preemption) during times of congestion."

And then you say:
"The details of these work items are outside the scope of the initial phase;
but the WG should consider their requirements to design components that are
sufficiently general to support such extensions in the future."

I think that the two above sentences contradict each other some how.
What you actually say in the second sentence is that the requirements of the
flow-rate adaptation during times of congestion should be considered to
design components that are sufficiently general to support such extensions
in the future. However, in the first paragraph you mention that flow-rate
adaptation during times of congestion might be considered, but it is not
sure that this will happen.
I will very much appreciate if you could change the following sentence:

Please change from:
"The WG may also consider to investigate additional response mechanisms that
act on (pre-)congestion signals. One example could be flow-rate adaptation
(rather than flow admission/preemption) during times of congestion."

INTO:
"The WG should consider to investigate additional response mechanisms that
act on (pre-)congestion signals. One example is the flow-rate adaptation
(rather than flow admission/preemption) during times of congestion."

Best Regards,
Georgios

> From: Jozef Babiarz [mailto:[email-masked]] 
> Sent: maandag 29 januari 2007 3:47
> To: Lars Eggert; [email-masked]
> Subject: RE: [PCN] charter, addition to scope
> 
> Lars,
> Do not understand why application aware (pre-)congestion is 
> out of scope? At the BOF in San Diego and on the PCN mailing 
> list there was support for it with people will to work on it. 
> Specifically what I would like to add to scope in the PCN 
> charter is that "the PCN WG will define requirements for 
> conveying (pre-)congestion information from the receiver to 
> the sender and the actions that both the receiving host and 
> (I thought I had sent this several days ago, but it 
> apparently never made it to the list?)
> 
> Hi,
> 
> below is a modified version of the PCN charter posted to this 
> list a while ago. I believe it reflects the consensus after 
> the face-to-face and mailing list discussions in and after Montreal.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 Jan 2007 11:37:49 +0100

Hi,

Georgios and Jozef, another reason for this charters look is that we ADs 
don't want the WG to try to boil the ocean. That is why we try to 
constrain the initial problem to solve to the most fundamental central 
parts of the problem. We do want the WG to be able to complete its 
initial milestones within a reasonable timeframe. If that is achieved 
and there still are interest and energy, I at least are very positive to 
a rechartering.

I know that this produce some issues when trying to draw up requirements 
for possible extension which hasn't been worked through. However to be 
realistic, we rather see a product that works for at least one set a 
problem then having no solution for many problems.

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 \(KI/EAB\)" <[email-masked]>
Date: Mon, 29 Jan 2007 11:46:57 +0100

My suggestion is to concentrate on describing the three involved
functions: 
1) traffic measurement function
2) protocol marking
3) triggering on admission control

and the "communication" between them.

We could in principle do that without any implementation constraints

My suggestion is that all of the algorithmic stuff are excluded from the
basic protocol specification as we have made in RMD. Algorithm is
targetted the implementation space.
 I think that the protocol should be support any algorithm. The only
difference will become the perfomance of them. I am very worried that we
will get into discussion about the favourite algorithm. 

I therefore suggest that the charter should have an explicit statement
that algorithms for marking should be excluded from the working group
documents

Regards Lasse

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: den 29 januari 2007 11:38
To: Georgios Karagiannis
Cc: [email-masked]
Subject: Re: [PCN] charter, addition to scope

Hi,

Cheers

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Mon, 29 Jan 2007 12:55:16 +0200

> that algorithms for marking should be excluded from the working group

I don't see how interior routers that implement different marking  
algorithms within one PCN region result in a system where the edge  
can know how to react. Or am I missing something?

Lars

---

From: "Lars Westberg \(KI/EAB\)" <[email-masked]>
Date: Mon, 29 Jan 2007 13:02:59 +0100

Some more explanation

As I understand, the purpose with marking is to generate blocking or rejection of resources. There are a few basic pronciple to to it i.e. rate-based marking. Exaclty how admission control function is measuring the marking is a implementation issue and when and exactly how the admission control react is is not needed to be described. Only some basic marking charactistics are needed. 

Many algorithms can be used even of the marking method is defined. One example is "how you measure the marking?" i.e weighted avereraging, fixed window, token bucket.... 
All of these methods is just an implementation of an measurement algorithm. The main consequence of different algorithms is the level of "overprovisioning" that is needed to cope with the wrong admission control decisions are different.

In general, the main problem is depednet of the following parameters: 
1)rate of admission control request. The rate of admission control request are different for different scenario: 
	-admission control for trunks 
	-per flow
	-the sources for admission control (MGW,,,,,) internal 		  functionality and reason for triggereing of a resource request.
2) expectation of utilization. If high utlization is expected, 
	an algorithm with high percision and increased complexity is 	required

3)what expected fault conditions should be covered by PCN? 
		- should it handle single fault or multiple faults. 
		a) spare capacity for single faults so PCN only 
		   cover blocking of new resource request.
		b) high utlization networks so PCN also must reject ongoing 		    admitted resources ?

We have done similar things for RMD and I think it is very important to avoid algoritmic description into the specifications. 

Regards Lasse

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: den 29 januari 2007 11:55
To: Lars Westberg (KI/EAB)
Cc: Magnus Westerlund (KI/EAB); Georgios Karagiannis; [email-masked]
Subject: Re: [PCN] charter, addition to scope

> that algorithms for marking should be excluded from the working group 

I don't see how interior routers that implement different marking algorithms within one PCN region result in a system where the edge can know how to react. Or am I missing something?

Lars

---

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Mon, 29 Jan 2007 09:20:58 -0500

Hi Lars and Lars,

It seems to me that we should neither say that the algorithms are
explicitly excluded, not try to standardize anything in the algorithms
beyond what is needed for interoperability.  The interoperability
requirements should in my opinion reflect the meaning/semantics of the
marking and hence the appropriate reaction of the edge devices to this
marking, and that in turn may restrict the range of flexibility of the
implementation/detailed algorithm.  One of the tasks of the WG would be
to decide exactly what that means. Sorry if this is stating the obvious.

Anna 

> Sent: Monday, January 29, 2007 5:55 AM
> To: ext Lars Westberg (KI/EAB)
> Cc: [email-masked]
> I don't see how interior routers that implement different 
> marking algorithms within one PCN region result in a system 
> where the edge can know how to react. Or am I missing something?
> 
> Lars
> 
> 
>

---

From: "Lars Westberg \(KI/EAB\)" <[email-masked]>
Date: Mon, 29 Jan 2007 15:32:02 +0100

Overprovisioning is a solution that can be solved with all different
algorithmic solution, so the gain with PCN (as far I can see) is mainly
bandwidth efficiency.

So I 100%-agreee that we should only standardize things that are
neccessary and visible on the interface between different routers.

I though of characteristics like: rate-based marking i.e that the
marking is perform with a certin average rate given a certain average
overload.

Regards Lasse

-----Original Message-----
From: Anna Charny (acharny) [mailto:[email-masked]] 
Sent: den 29 januari 2007 15:21
To: Lars Eggert; Lars Westberg (KI/EAB)
Cc: [email-masked]
Subject: RE: [PCN] charter, addition to scope

Hi Lars and Lars,

Anna 

> algorithms within one PCN region result in a system where the edge can

> know how to react. Or am I missing something?
> 
> Lars
> 
> 
>

---

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Mon, 29 Jan 2007 10:04:52 -0500

Hi Lasse,

I wonder if we may end up needed somewhat more that what (I think) you
are proposing.  A decision to make marking a function of the overload
(which is I think what your suggestion means) is an important one. Note
the semantics of the admission/pre-congestion marking proposed in
current CL- drafts is not proportional to the overload - it would result
in a 100% marking for consistent overload.  It is not clear how the
system would work if some devices do CL-style marking and some do, for
example, overload-proportional marking.  So one of the decisions the WG
would need to make is which way to go on this.

Anna 

> From: Lars Westberg (KI/EAB) [mailto:[email-masked]] 
> Sent: Monday, January 29, 2007 9:32 AM
> To: Anna Charny (acharny); Lars Eggert
> Cc: [email-masked]
> Overprovisioning is a solution that can be solved with all 
> different algorithmic solution, so the gain with PCN (as far 
> I can see) is mainly bandwidth efficiency.
> 
> So I 100%-agreee that we should only standardize things that 
> are neccessary and visible on the interface between different routers.
> 
> I though of characteristics like: rate-based marking i.e that 
> the marking is perform with a certin average rate given a 
> certain average overload.
> 
> Regards Lasse
> 
> It seems to me that we should neither say that the algorithms 
> are explicitly excluded, not try to standardize anything in 
> the algorithms beyond what is needed for interoperability.  
> The interoperability requirements should in my opinion 
> reflect the meaning/semantics of the marking and hence the 
> appropriate reaction of the edge devices to this marking, and 
> that in turn may restrict the range of flexibility of the 
> implementation/detailed algorithm.  One of the tasks of the 
> WG would be to decide exactly what that means. Sorry if this 
> is stating the obvious.
> 
> Anna 
>

---

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Mon, 29 Jan 2007 09:11:48 -0600

Folks,

Would it make sense to borrow a page from the legacy TDN network
management controls? There you can signal the percentage of new attempts
that should be discarded and the percentage can thus be adjusted up or
down to fine tune the load to match the capacity at the core. There is
also a gapping scheme where you don't specify the degree that blocking
should occur, but rather an admittance rate of X calls per unit time Y. 

Stuart Goldman
Alcatel-Lucent 

-----Original Message-----
From: Anna Charny (acharny) [mailto:[email-masked]] 
Sent: Monday, January 29, 2007 8:05 AM
To: Lars Westberg (KI/EAB); Lars Eggert
Cc: [email-masked]
Subject: RE: [PCN] charter, addition to scope

Hi Lasse,

Anna

---

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Mon, 29 Jan 2007 09:17:35 -0600

Folks,

I am a bit confused about one item in this scheme. As I understand the
principle, when the core senses that it is approaching congestion, the
edge nodes are requested to reduce their offerings. What is the
motivation for a given edge node to do so? It seems that if the other
edge nodes do reduce their offerings then a "renegade" edge node could
take advantage of the reduction in traffic at the core to continue to
send his traffic.  Such behavior would logically lead the others to
follow unless there was some sort of policing.

Am I missing something?

Stuart Goldman
Alcatel-Lucent 

-----Original Message-----
From: Anna Charny (acharny) [mailto:[email-masked]] 
Sent: Monday, January 29, 2007 7:21 AM
To: Lars Eggert; ext Lars Westberg (KI/EAB)
Cc: [email-masked]
Subject: RE: [PCN] charter, addition to scope

Hi Lars and Lars,

Anna

---

From: Lars Eggert <[email-masked]>
Date: Mon, 29 Jan 2007 17:26:20 +0200

On 2007-1-29, at 17:17, ext GOLDMAN, STUART O (STUART) wrote:
> edge nodes are requested to reduce their offerings.

Under the initial model, it is the edge *routers* that are acting on  
the signal from the interior. Which is why all routers need to trust  
each other.

> What is the

Right, all these issues (and others) exist with the host-to-host  
deployment scenario, which is why we're declaring this to be out-of- 
scope initially.

Lars

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 29 Jan 2007 19:39:19 -0500

>deployment scenario, which is why we're declaring this to be out-of- 

I have slightly different view.

In the first phase of PCN work to reduce the list of issues it was
proposed that the WG focus on network deployment scenario where all
nodes can be trusted and delay work on deployment scenarios where some
of the nodes are not trusted. I have no issue with delaying work on
cheater detection and enforcement. I believe there are methods that can
be used to detect, discourage or even stop devices from cheating with
the PCN mechanism. 

On comment host-to-host:
Currently, there are examples of scenarios where hosts are trusted by
the network. Some examples are, 3G wireless terminal, media gateways, IP
telephone sets connected in enterprise networks, enterprises run
"plug-in modules" that verifies/enforces hardware and software the
employees can run on their personal computers when they connect to their
network. So I do not agree that so called host-to-host deployment has a
trust that is non starter for PCN workgroup to address.

The trust issue will need to be address if PCN mechanism is to be used
in open networks like the Internet, where an ingress router can not
trust its neighbor ingress router or an egress routers or any other node
that connects to the network (e.g., media gateway, wireless access
point, IP telephone sets, personal computers, servers, etc.) that my be
associated with the PCN mechanism.   

Regards, Joe
-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: January 29, 2007 10:26 AM
To: ext GOLDMAN, STUART O (STUART)
Cc: [email-masked]
Subject: Re: [PCN] charter, addition to scope

Lars

---

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Mon, 29 Jan 2007 19:21:39 -0600

Joe,

Thanks for the input. While I am still concerned about not addressing
the trust concern until a later phase, I accept your belief that it can
be successfully resolved. I will wait patently until we get to that
phase.

Stuart Goldman
Alcatel-Lucent 

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: Monday, January 29, 2007 5:39 PM
To: Lars Eggert; GOLDMAN, STUART O (STUART)
Cc: [email-masked]
Subject: RE: [PCN] charter, addition to scope

On comment host-to-host:

Regards, Joe
-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: January 29, 2007 10:26 AM
To: ext GOLDMAN, STUART O (STUART)
Cc: [email-masked]
Subject: Re: [PCN] charter, addition to scope

Lars

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 30 Jan 2007 08:33:28 +0100

Stuart,

the issue you raise is currently not a chartered work item. Bob 
Briscoe already started thinking about counter measures. His  
draft-briscoe-tsvwg-re-ecn-border-cheat-01 recently expired.

Regards,

Ruediger

|-----Original Message-----
|From: GOLDMAN, STUART O (STUART) [mailto:[email-masked]]
|Sent: Monday, January 29, 2007 4:18 PM
|To: Anna Charny (acharny); Lars Eggert; ext Lars Westberg (KI/EAB)
|Cc: [email-masked]
|Subject: RE: [PCN] charter, addition to scope
|
|
|Folks,
|
|I am a bit confused about one item in this scheme. As I understand the
|principle, when the core senses that it is approaching congestion, the
|edge nodes are requested to reduce their offerings. What is the
|motivation for a given edge node to do so? It seems that if the other
|edge nodes do reduce their offerings then a "renegade" edge node could
|take advantage of the reduction in traffic at the core to continue to
|send his traffic.  Such behavior would logically lead the others to
|follow unless there was some sort of policing.
|
|Am I missing something?
|
|Stuart Goldman
|Alcatel-Lucent 
[email-masked]
|602 493 8438
|
|
|
|-----Original Message-----
|From: Anna Charny (acharny) [mailto:[email-masked]] 
|Sent: Monday, January 29, 2007 7:21 AM
|To: Lars Eggert; ext Lars Westberg (KI/EAB)
|Cc: [email-masked]
|Subject: RE: [PCN] charter, addition to scope
|
|Hi Lars and Lars,
|
|It seems to me that we should neither say that the algorithms are
|explicitly excluded, not try to standardize anything in the algorithms
|beyond what is needed for interoperability.  The interoperability
|requirements should in my opinion reflect the meaning/semantics of the
|marking and hence the appropriate reaction of the edge devices to this
|marking, and that in turn may restrict the range of flexibility of the
|implementation/detailed algorithm.  One of the tasks of the WG would be
|to decide exactly what that means. Sorry if this is stating 
|the obvious.
|
|Anna 
|
|> -----Original Message-----
|> From: Lars Eggert [mailto:[email-masked]] 
|> Sent: Monday, January 29, 2007 5:55 AM
|> To: ext Lars Westberg (KI/EAB)
|> Cc: [email-masked]
|> Subject: Re: [PCN] charter, addition to scope
|> 
|> On 2007-1-29, at 12:46, ext Lars Westberg (KI/EAB) wrote:
|> > I therefore suggest that the charter should have an 
|> explicit statement 
|> > that algorithms for marking should be excluded from the 
|> working group 
|> > documents
|> 
|> I don't see how interior routers that implement different 
|> marking algorithms within one PCN region result in a system 
|> where the edge can know how to react. Or am I missing something?
|> 
|> Lars
|> 
|> 
|> 
|
|_______________________________________________
|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: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 30 Jan 2007 12:16:42 -0500

Lars:
By the last sentence of your E-Mail,
I think you are equating "Application Control Deployment" with "host-to-host".
Which may be your reasoning for excluding "Application Control Deployment".

"Application Control Deployment" can be "edge-to-edge", which will very much
use the same behaviors and mechanisms that we can standardize in PCN.

Hence IMHO, the "Application Control Deployment" for "edge-to-edge" 
fits very well
within the work being done in the first phase of PCN and should be included as
a work item (informational track) for the first phase of PCN.

Please separate the notion of "host-to-host" from "Application 
Control Deployment".
Thanks!
-- Kwok --

---

From: Lars Eggert <[email-masked]>
Date: Wed, 31 Jan 2007 10:37:06 +0200

On 2007-1-30, at 2:39, ext Jozef Babiarz wrote:
> of the nodes are not trusted.

If by "nodes" you mean routers, then yes, I agree. If "nodes" include  
end systems, proxies or other entities, then I don't agree we had  
agreement on that.

> trust that is non starter for PCN workgroup to address.

I don't dispute that examples exists where mutual trust exists among  
the routers, hosts and other boxes in the network. But there are  
clearly many cases where such trust doesn't exist. At and after the  
BOF, there was agreement that the case where such trust exists  
between the routers of a single network domain had been described in  
sufficient detail to be solvable by the IETF. When the trust extended  
to other nodes, that agreement wasn't there.

> associated with the PCN mechanism.

Completely agree. Which is why we're limiting the scope of the  
initial problem to a single network domain. How PCN operates when  
some or even most of the routers or other nodes aren't trusted is an  
open problem.

Lars

---

From: Lars Westberg <[email-masked]>
Date: Wed, 31 Jan 2007 09:58:40 +0100

If I interprete you correctly, examples are lacking, for trust to other 
nodes ?

What do we needed to proof that it exists ?
Examples from telecom networks ?

or, are  telecom networks out-of-scope from IETF-perspective ?

regards Lasse

---

From: Lars Eggert <[email-masked]>
Date: Wed, 31 Jan 2007 11:02:38 +0200

On 2007-1-31, at 10:58, ext Lars Westberg wrote:
> If I interprete you correctly, examples are lacking, for trust to  
> other nodes ?

Read again. I said I _don't_ dispute that such examples exist.

Lars

---

From: Lars Westberg <[email-masked]>
Date: Wed, 31 Jan 2007 10:12:06 +0100

what is the problem?
Is trust between routers more common than the other scenario?
One problem I forsee it that the architecture for routers may include 
limitations for thw other scenario.

What is the way forward?
wait to the next re-charter 3-year ahead ?

regards Lasse

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 31 Jan 2007 12:37:08 +0100

Hi Lars

Please see in line!
 
> (by Lars:) If by "nodes" you mean routers, then yes, I agree. If "nodes" 
> include end systems, proxies or other entities, then I don't 
> agree we had agreement on that.

Georgios: This imposes an additional restriction on the scope 
of the charter, which has been not discussed yet.
>From what I remember before, during and after the PCN BOF 
there was no objection on using 
the term edge node, that could mean something different than a edge router.
Please note that this is something different than a scenario covered by 
an application based deployment model.

Note that we have used this term in the first version of the 
PCN BOF charter and also 
the draft:
http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-01.txt

Is it okay with you if end nodes could be gateways/routers?

> > the network. Some examples are, 3G wireless terminal, media 
> gateways, 
> > IP telephone sets connected in enterprise networks, enterprises run 
> > employees can run on their personal computers when they connect to 
> > their network. So I do not agree that so called host-to-host 
> > deployment has a trust that is non starter for PCN workgroup to 
> > address.
> 
> (by Lars: ) I don't dispute that examples exists where mutual trust 
> exists among the routers, hosts and other boxes in the 
> network. But there are clearly many cases where such trust 
> doesn't exist. At and after the BOF, there was agreement that 
> the case where such trust exists between the routers of a 
> single network domain had been described in sufficient detail 
> to be solvable by the IETF. When the trust extended to other 
> nodes, that agreement wasn't there.

Georgios: From the point of security vulnerabilities I am not sure 
if there are main differences between the scenario that one trusted domain
is used 
or the scenario where two or more concateneted 
trusted domains are used. Note that the two or more concateneted trusted 
domains can be seen as one trusted domain (from the point of security 
vulnerabilities)

> > trust its neighbor ingress router or an egress routers or any other 
> > node that connects to the network (e.g., media gateway, wireless 
> > access point, IP telephone sets, personal computers, servers, etc.) 
> > that my be associated with the PCN mechanism.
> 
> Completely agree. Which is why we're limiting the scope of 
> the initial problem to a single network domain. How PCN 
> operates when some or even most of the routers or other nodes 
> aren't trusted is an open problem.
> 
> Lars

Best Regards,
Georgios

---

From: <[email-masked]>
Date: Wed, 31 Jan 2007 11:53:49 -0000

> Sent: 26 January 2007 09:17

also, once actual congestion is occurring then the QoS of all flows is
degraded. Rather than risk this happening, some may prefer to protect
the QoS of (most) existing flows by pre-empting a (few) flows.

---

From: <[email-masked]>
Date: Wed, 31 Jan 2007 11:59:44 -0000

> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 29 January 2007 09:37
> To: 'Lars Eggert'; [email-masked]
> "The WG may also consider to investigate additional response
mechanisms
> that
> but the WG should consider their requirements to design components
that
> are
> What you actually say in the second sentence is that the requirements
of
> the
> "The WG may also consider to investigate additional response
mechanisms
> that

I think you're suggesting saying now what will definitely be in a
re-charter. This doesn't sound possible to me. 
(incidentally, personally I think the case of flow-rate adaptation based
on pre-congestion marks is rather different - eg will be hard to
translate lessons from the work from simulations/ performance analysis
during the work of the initial charter.)

---

From: Lars Westberg <[email-masked]>
Date: Wed, 31 Jan 2007 13:01:43 +0100

may I do not have the background for the decissions and  I haven't got 
any reply on my questions yet.

I have gotten simillar  respone two times and I think that we have two 
choices:

1) discuss it somewhere else in another standardization body.
2) initiate a new BOF for this task.

I don't understand the decision. Admission control function is typical 
function i n MGW not in backbone routers.

regards Lasse

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 31 Jan 2007 13:06:02 +0100

Hi Kwok

You are very right the "Application Control Deployment" 
can be "edge-to-edge" and not host-to-host.
I think that this is a matter of right terminology.

Best Regards,
Georgios

> From: Kwok-Ho Chan [mailto:[email-masked]] 
> Sent: dinsdag 30 januari 2007 18:17
> To: Lars Eggert
> Cc: [email-masked]
> "Application Control Deployment" can be "edge-to-edge", which 
> will very much use the same behaviors and mechanisms that we 
> can standardize in PCN.
> 
> within the work being done in the first phase of PCN and 
> should be included as a work item (informational track) for 
> the first phase of PCN.
> 
> Please separate the notion of "host-to-host" from 
> "Application Control Deployment".
> Thanks!
> -- Kwok --
> 
>

---

From: <[email-masked]>
Date: Wed, 31 Jan 2007 12:45:07 -0000

> Sent: 31 January 2007 11:37
> To: 'Lars Eggert'; 'ext Jozef Babiarz'
> Cc: [email-masked]

the charter says a "single Diffserv region". DS region [rfc2475] " a set
of contiguous DS domains which can offer differentiated services over
paths across those DS domains."

---

From: <[email-masked]>
Date: Wed, 31 Jan 2007 12:54:11 -0000

> From: ken carlberg [mailto:[email-masked]]
> Sent: 25 January 2007 16:37
> To: Lars Eggert
> Cc: [email-masked]

Ken,
I remember thinking about this before the BoF, when we were
experimenting with wordings for the BoF. It proved (to my surprise)
difficult to find a wording that worked. 
For example, saying something like "the WG will specify a mechanism to
determine how much excess traffic is; the WG will not specify a required
reaction to this information, but it will write an Info on flow
pre-emption as one possible reaction (which may not be allowed for legal
/regulatory reasons)"

The problem is that this assumes the mechanism will work by measuring
the excess traffic. Although this is the way described in the CL-drafts,
others have in mind a different method.

So instead we went back to saying that the WG will standardise how the
edge makes a pre-emption decision, but ruling handling of emergency
calls as out of scope.  so as to rule out thinking about nasty
legal/regulatory issues. But hopefully you can find a better phrasing!

However, I think I disagree with you when you say "preemption as one of
several (re)actions that can be advanced by the group". I think that in
the initial charter that the WG should advance only one "(re)action" ie
flow pre-emption (as well as adm ctrl). Other possible reactions (say
adapting rate of flows) should be after re-chartering.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 31 Jan 2007 14:01:53 +0100

> I think that this is a matter of right terminology.

Independent of that, there is no good description of what this would 
mean. draft-babiarz-pcn-sip-cap-00 seems to only talk about end-to-end 
cases. Or at least where the PCN aware equipment would reside outside a 
PCN domain.

The problem from Lars Eggert and my perspective is that there is no 
consensus on what application control means in this scenario while it is 
reasonably simple to understand using RSVP towards a PCN domain, and 
using PCN information to determine if the reservation is acceptable or not.

Cheers

Magnus Westerlund

---

From: ken carlberg <[email-masked]>
Date: Wed, 31 Jan 2007 08:49:47 -0500

Phil,

> legal/regulatory issues. But hopefully you can find a better phrasing!

I debated whether to respond to something similar stated by Lars E.,  
but since you are touching on the same thing I'll speak up now.  The  
subjects of pre-emption and emergency calls/services are some what  
tangential to each other.  I understand the position that how  
emergency calls are handled (the protocols/mechanisms) is out of  
scope.  No problem.

However, put simply, preemption involving the PSTN in some countries  
(eg, USA and Germany) is simply not allowed under *any*  
conditions....regardless if there are emergency calls or not.  And  
given that those VoIP providers that bridge to the PSTN tend to be  
subject to the same regulations as the PSTN (eg, required support for  
911), then I _think_ its a safe bet that this restriction of  
preemption applies as well.

So all I'm advocating for is making sure the group doesn't paint  
itself into a corner.  Until other (re)actions are defined, or  
regulations are changed, deployment would seem to be limited for  
preemption as a (re)action.

> adapting rate of flows) should be after re-chartering.

I have no issues in advancing one (re)action in the first iteration  
of the WG.  I just think its important that the WG makes it clear in  
the proposed charter that other (re)actions can exist, and in its  
work agrees on the hooks to allow this to happen.

-ken

---

From: <[email-masked]>
Date: Wed, 31 Jan 2007 13:46:28 -0000

I'm not sure, but I think there may be violent agreement.

Thinking only about PCN mechanisms running edge-to-edge, which is what's
in scope in Lars's charter. In terms of how new flows are requested:

- we have what is described in
draft-briscoe-tsvwg-cl-architecture-04.txt.  RSVP from end host reaches
PCN-region ingress gateway, which checks the current
Congestion-Level-Estimate for the relevant ingress-egress-aggregate, and
hence decides whether to admit the new flow request. 

- I can imagine an alternative (which I think is "Application Control
Deployment" or Lars W's MGW case) where some signalling from the end
host (not RSVP) reaches an 'admission controller', which is in the
PCN-region but is not (necessarily) on the data path (if the flow is
admitted). The 'admission controller' would work out what the
PCN-ingress & PCN-egress would be (eg if the call is admitted, the data
will enter the PCN-region via this ingress). It would then discover what
the current Congestion-Level-Estimate for the relevant
ingress-egress-aggregate, and hence decides whether to admit the new
flow request.

- case 2 sounds reasonable to me, but is not really described anywhere
at the moment (draft-babiarz-pcn-sip-cap-00.txt touches it, but that
draft is really about the host-to-host case)

- case 2 isn't explicitly in or out of the current draft charter 

- what would including case 2 impact? (in terms of the Charter work
items). I think it's only the architecture doc that would change (get an
extra section), and even that is mainly in terms of operation outside
the PCN-region. technical arguments about the right encoding, marking
behaviour etc won't be altered. To me this suggests it's easier to
exclude it, just so there's less to write, but I don't really mind.
However, if I'm wrong and it will change the technical arguments then it
probably should be included (but please hint why/how now!)  

best wishes,
phil
> Sent: 31 January 2007 12:06
> To: 'Kwok-Ho Chan'; 'Lars Eggert'
> Cc: [email-masked]

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 31 Jan 2007 15:11:49 +0100

Hi Magnus

In the following draft we have tried to somehow explain what a PCN regios is
and which
nodes it has to use:
http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-01.txt

In order to satisfy your concerns I have changed a bit the used terms, see
below. 
Please note that I have changed the term PCN End Node 
to PCN Edge Node. Furthermore, I removed the term end hosts:

   PCN-Region:

         A DiffServ region of the Internet running PCN, that is the PCN-
         based mechanisms are used to decide whether to admit a new flow
         to the DiffServ region and whether to pre-empt an existing
         flow.  All traffic enters/leaves the PCN-Region through a PCN
         Edge Node.  Please note that the PCN-Region is also defined by
         the Diffserv Service Class [18] that is subject to the PCN
         mechanisms.

   PCN Interior Node (PIN) (function):

         The PCN Interior Node is an "on-path" function.  It performs
         traffic metering and PCN-marking: the function that enables a
         network element to give an early warning of its own incipient
         congestion ("pre-congestion") on one of its interfaces, ie
         traffic is above a certain level, by marking, e.g. changing the
         header of packet(s).

   PCN Edge Node (PEN) (function):

         The PCN Edge Node is an "on-path" function.  The PCN Edge Node is
         where the PCN Region ends.  It indicates the significance of
         the PCN packet marking which terminates at this functional
         node.  This functional description does not imply which
         physical device will implement this function (e.g., edge
         router, media gateway).  This "on-path" function
         performs the detection of PCN-marks: the function that monitors
         PCN-marking to obtain on-path congestion information as
         signaled through PCN-marking by PCN-enabled Interior Nodes.

Best Regards,
Georgios

> Sent: woensdag 31 januari 2007 14:02
> To: Georgios Karagiannis
> Cc: 'Kwok-Ho Chan'; 'Lars Eggert'; [email-masked]
> Independent of that, there is no good description of what 
> this would mean. draft-babiarz-pcn-sip-cap-00 seems to only 
> talk about end-to-end cases. Or at least where the PCN aware 
> equipment would reside outside a PCN domain.
> 
> The problem from Lars Eggert and my perspective is that there 
> is no consensus on what application control means in this 
> scenario while it is reasonably simple to understand using 
> RSVP towards a PCN domain, and using PCN information to 
> determine if the reservation is acceptable or not.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 31 Jan 2007 15:39:35 +0100

Ken, Phil

what you say is that "preemption" must not be the only reaction 
specified by PCN once an ingress edge router determines that 
the path to a particular egress router reached 
congestion/preemption state? 

If yes, I agree. Would the charter have to say so or should 
this be a design constraint to be kept in mind when drafting 
standards?

The minimum requirement may be to demand that the deactivation 
of a preemption mechanism must be possible (the PCN domain 
would then always interpret congestion marks in the same way as 
pre-congestion marks ). In the trusted inter domain case, both 
ends may follow different implementations. PCN should ensure 
interoperability then.

I now also understand Jozef Babiarz proposal to change 
"preemption" to "congestion" in the charter. The behaviour 
"Preemption" would then be one option how to react on congestion.
And the PCN WG must work on the preemption behaviour, but also 
must allow for operation without it.

Jozefs proposed new charter simply replaced "preemption" by 
"congestion", if I recall right. May be doing so but adding a 
statement on using the state "congestion" to trigger 
preemption (as one possible reaction) could help to clarify 
the charter? 
 
Regards,

Ruediger

|-----Original Message-----
|From: ken carlberg [mailto:[email-masked]]
|Sent: Wednesday, January 31, 2007 2:50 PM
|To: [email-masked]
|Cc: [email-masked]
|Subject: Re: [PCN] charter text update
|
|
|Phil,
|
|> So instead we went back to saying that the WG will standardise how
the
|> edge makes a pre-emption decision, but ruling handling of emergency
|> calls as out of scope.  so as to rule out thinking about nasty
|> legal/regulatory issues. But hopefully you can find a better
phrasing!
|
|I debated whether to respond to something similar stated by Lars E.,  
|but since you are touching on the same thing I'll speak up now.  The  
|subjects of pre-emption and emergency calls/services are some what  
|tangential to each other.  I understand the position that how  
|emergency calls are handled (the protocols/mechanisms) is out of  
|scope.  No problem.
|
|However, put simply, preemption involving the PSTN in some countries  
|(eg, USA and Germany) is simply not allowed under *any*  
|conditions....regardless if there are emergency calls or not.  And  
|given that those VoIP providers that bridge to the PSTN tend to be  
|subject to the same regulations as the PSTN (eg, required support for  
|911), then I _think_ its a safe bet that this restriction of  
|preemption applies as well.
|
|So all I'm advocating for is making sure the group doesn't paint  
|itself into a corner.  Until other (re)actions are defined, or  
|regulations are changed, deployment would seem to be limited for  
|preemption as a (re)action.
|
|> However, I think I disagree with you when you say "preemption as  
|> one of
|> several (re)actions that can be advanced by the group". I think  
|> that in
|> the initial charter that the WG should advance only one "(re) 
|> action" ie
|> flow pre-emption (as well as adm ctrl). Other possible reactions (say
|> adapting rate of flows) should be after re-chartering.
|
|I have no issues in advancing one (re)action in the first iteration  
|of the WG.  I just think its important that the WG makes it clear in  
|the proposed charter that other (re)actions can exist, and in its  
|work agrees on the hooks to allow this to happen.
|
|-ken
|
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: Lars Westberg <[email-masked]>
Date: Wed, 31 Jan 2007 15:59:32 +0100

I think it is some mis-understanding.
I am not refering to end-p2-end scenarios. I am refering telecom 
scenario where MGWs are connected to an IP-backbone. In these scenarios, 
the admission control function is a part of the MGW and not the routers. 
The IP-backbone is provisioned by a network managmenent systen.
We are refering to a scenario when bandwidth (in the network) are shared 
among a number of entities that are connected to the same multi-service 
backbone.

In some way, the notification has to be sent to the MGW. The MGW can 
block calls (reduce the traffic vlume) and the edge-router can dropping 
packet. However, packet drops is not recommended for the sensitive traffic.

Therefore, some interation has to be there and I do not understand why 
we only limit the scenario to admission control in a edge-routers. Some 
vendors might be interested in this sceario, but I am worried that this 
will put restriction of the architecture.

so, once again, give a summary of the reasons not to include Admission 
control into other entities than  routers.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 31 Jan 2007 17:31:59 +0200

Hi,

the recent emails by Ken, Phil and you helped a lot. I think we  
actually may be in agreement.

> this be a design constraint to be kept in mind when drafting

The charter already allows a reaction other than preemption, namely,  
to prevent admission of new flows. Additionally, there was some  
discussion around having a rate-adaptation reaction function.

Would a slightly-reworded statement taken from an earlier version of  
the charter help:

	Although designed to work together, flow admission and
	flow preemption are independent mechanisms, and the use
	of one does not require or prevent the use of the other.

> pre-congestion marks ).

There seems to be an unstated assumption here that congestion marks  
will always lead to preemption, while pre-congestion marks will lead  
to admission decisions. This is not so - the current charter allows  
different policies, i.e., meaning decision algorithms that take  
congestion and pre-congestion markers as input and produce preemption  
and admission decisions on the set of flows as an output.

A policy that would only ever issue admission decisions is certainly  
possible.

> must allow for operation without it.

Right. Admission decisions are the other reaction mechanism.

> preemption (as one possible reaction) could help to clarify

I don't see how making this replacement and then explaining what it  
means by using the replaced term is making anything more clear.

Lars

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 31 Jan 2007 12:03:26 -0500

Philip and all,

To some people *preemption*, "means the removal of a call to make room
for a new call to be admitted". In the PCN work we have modified the
meaning of preemption to "the removal of excess (that causes congestion)
traffic at flow granularity level".

I think we should think about using a different word or term so that
people directly not involved with PCN WG do not get confused, just a
suggestion. Personally, I like preemption, but if it will make the
charter approval process go faster by using a different term, I'm for
the changing it. 

Regards, Joe

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: January 31, 2007 7:54 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [PCN] charter text update

Ken,

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 31 Jan 2007 18:07:55 +0100

Hi Phil 

Please see in line!
> > "After completion of the initial phase, the PCN WG may 
> re-charter to 
> > not in
> place.
> > It may also re-charter to consider applying the PCN mechanisms to 
> > additional deployment scenarios (operation over 
> concatenated DiffServ 
> (pre-)congestion
> > admission/preemption) during times of congestion. The 
> details of these 
> > work items are outside the scope of the initial phase; but the WG 
> > should consider their requirements to design components that are 
> > sufficiently general
> to
> > "The details of these work items are outside the scope of 
> the initial 
> > phase; but the WG should consider their requirements to design 
> > components
> that
> > are
> > "The WG should consider to investigate additional response 
> mechanisms
> that
> I think you're suggesting saying now what will definitely be 
> in a re-charter. This doesn't sound possible to me. 
> (incidentally, personally I think the case of flow-rate 
> adaptation based on pre-congestion marks is rather different 
> - eg will be hard to translate lessons from the work from 
> simulations/ performance analysis during the work of the 
> initial charter.)

No, what I am saying here is that the flow rate adaptaion scenario 
can be considered after rechartering, but the requirements imposed by a 
flow-rate adaptation scenario should be considered already in the first 
phase.

Best Regards,
Georgios

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 31 Jan 2007 12:14:10 -0500

Phil, LarsE, All:
Please see my comments enclosed with KHC_START> and KHC_END>.
Thanks!
-- Kwok --

>- case 2 isn't explicitly in or out of the current draft charter

KHC_START>
IMHO, case 2 should be explicitly INCLUDED in the current draft charter.
And I will be happy to give it a try on adding a sentence or two for it.
KHC_END>

>probably should be included (but please hint why/how now!)

KHC_START>
When I looked at the 2nd charter text update, I found the standardization work
will pretty much be the same for both case 1 and case 2 you indicated above.
With the additional work of providing an Information document that 
will describe
the deployment scenario when Application Control is used Edge-to-Edge, which
we have a good handful of people volunteering to do the work.
Hence my suggestion of making "Application Control for Edge-to-Edge Deployment"
be included by the proposed charter and possibly adding such a deliverable in
the milestone part of the charter.
KHC_END>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 31 Jan 2007 18:19:52 +0100

Hi Kwok

I agree with your below suggestion.

> be included by the proposed charter and possibly adding such 
> a deliverable in the milestone part of the charter.

Best Regards,
Georgios

> Sent: woensdag 31 januari 2007 18:14
> To: [email-masked]
> Cc: [email-masked]; Kwok-Ho Chan; 
> [email-masked]; [email-masked]
> >Thinking only about PCN mechanisms running edge-to-edge, which is 
> >what's in scope in Lars's charter. In terms of how new flows 
> are requested:
> >
> >Congestion-Level-Estimate for the relevant ingress-egress-aggregate, 
> >and hence decides whether to admit the new flow request.
> >
> >will enter the PCN-region via this ingress). It would then discover 
> >what the current Congestion-Level-Estimate for the relevant 
> >items). I think it's only the architecture doc that would 
> change (get 
> >an extra section), and even that is mainly in terms of operation 
> >outside the PCN-region. technical arguments about the right 
> encoding, 
> >marking behaviour etc won't be altered. To me this suggests 
> it's easier 
> >to exclude it, just so there's less to write, but I don't 
> really mind.
> >However, if I'm wrong and it will change the technical 
> arguments then 
> >it probably should be included (but please hint why/how now!)
> 
> KHC_START>
> When I looked at the 2nd charter text update, I found the 
> standardization work will pretty much be the same for both 
> case 1 and case 2 you indicated above.
> With the additional work of providing an Information document 
> that will describe the deployment scenario when Application 
> Control is used Edge-to-Edge, which we have a good handful of 
> people volunteering to do the work.
> be included by the proposed charter and possibly adding such 
> a deliverable in the milestone part of the charter.
> KHC_END>
> 
> 
> >best wishes,
> >phil
> > > > >Under the initial model, it is the edge *routers* that 
> are acting
> >on
> > > > >>send his traffic.  Such behavior would logically lead 
> the others
> >to

---

From: [email-masked]
Date: Wed, 31 Jan 2007 14:30:07 -0500

> an application based deployment model.

It's certainly not a new restriction based on the discussion in the
BOF engendered about whether a SIP telephone (used on some of the
slides) was a good example.  I believe the BOF conclusion was that
a SIP telephone was a bad example.

IMHO, a SIP telephone causes two sets of issues wrt the proposed work:
	(1) It speaks SIP, and 
	(2) It's a telephone ;-)
The first set of issues  has already been discussed extensively - my
understanding is that the SIP scenario is currently out of scope, and
I don't care to reopen that discussion.

The "telephone" issues come up in two ways:
(2a) Small number of flows may make relatively fine-grained adjustment
	on the link to the phone impossible.  The PCN work prior to
	the BOF relied on the ability to make such adjustments.
(2b) While other sorts of phones may be trusted, a SIP phone (which
	may be software-only) is definitely not trustable in general.

I would observe that Lars Westerberg's suggestion of a Media Gateway:

> I am referring telecom scenario where MGWs are connected to an
IP-backbone.
> In these scenarios, the admission control function is a part of the
MGW
> and not the routers. The IP-backbone is provisioned by a network
> management system.

could avoid all of these issues:
(1) The media gateway could speak RSVP to the network management system,
	avoiding any need to deal with SIP here.
(2a) A media gateway is likely to handle enough flows to be consistent
	with the fine-grained adjustment assumed by the work done to
date.
(2b) One can plausibly assume/require that media gateways be trusted
	with respect to the IP network.
To the extent that one can vest "edge" functionality in a trusted
media gateway, I see no reason to exclude that scenario.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------