Subject: [PCN] 2nd charter text update

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

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 network domain when congestion is imminent or  
existing. These mechanisms operate at the domain edge, based on  
aggregated congestion and pre-congestion signals from within the  
domain. The focus of the WG is on developing standards for the  
marking behavior of the interior routers and the encoding of the  
congestion signals. Reaction mechanisms at the edge include flow  
admission and flow preemption. The WG may produce informational  
documents that describe how specific quality-of-service policies can  
be implemented using a combination of these mechanisms.

The PCN 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, preemption or
        rate adaption, based on aggregated (pre-)congestion information

The WG focuses on the overall architecture and the marking behavior  
and signaling interface 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 initial scope of the PCN WG is restricted in the following ways:

    (A) develop these components for a single DiffServ region,
        where all edge and interior routers 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) 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 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.

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: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 29 Jan 2007 12:09:23 +0200

The previous version of the charter proposal included: 

 7. an analysis of the manageability issues of a PCN region

As well as

July 2007         initial manageability issues document Internet Draft
...
Nov 2007          submit manageability issues document to IESG for
approval as informational RFC 

When and why did those disappear? 

Dan

> -----Original Message-----
> From: ext Lars Eggert [mailto:[email-masked]] 
> Sent: Monday, January 29, 2007 11:09 AM
> To: [email-masked]
> Subject: [PCN] 2nd charter text update
> 
> The Congestion and Pre-Congestion Notification (PCN) working 
> group develops mechanisms to protect the quality-of-service 
> of established flows within a network domain when congestion 
> is imminent or existing. These mechanisms operate at the 
> domain edge, based on aggregated congestion and 
> pre-congestion signals from within the domain. The focus of 
> the WG is on developing standards for the marking behavior of 
> the interior routers and the encoding of the congestion 
> signals. Reaction mechanisms at the edge include flow 
> admission and flow preemption. The WG may produce 
> informational documents that describe how specific 
> quality-of-service policies can be implemented using a 
> combination of these mechanisms.
> 
> The PCN WG will specify the following components of an 
> integrated flow admission and preemption mechanism:
> 
> The WG focuses on the overall architecture and the marking 
> behavior and signaling interface 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.
> 
> 
>         is sufficiently large for stateless, statistical 
> mechanisms to be
>         effective
> 
> 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.
> 
> 
> Goals and Milestones:
>

---

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

> When and why did those disappear?

Good point. I had sort of assumed that these were part of the  
architecture document. Do you see a specific need for a standalone  
document, or should I simply make it a bit clearer in the text where  
those considerations are to be addressed?

Lars

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 29 Jan 2007 13:18:36 +0200

It's up to the working group to decide whether they want to make out of
the manageability considerations a separate document or include them in
the architecture or other document. The main point right now is to say
specifically in the charter what they decided to do. 

Dan

> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Monday, January 29, 2007 12:52 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [PCN] 2nd charter text update
> 
> architecture document. Do you see a specific need for a 
> standalone document, or should I simply make it a bit clearer 
> in the text where those considerations are to be addressed?
> 
> Lars
> 
> 
>

---

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

Folks,

While it is up to the working group if an additional document is the way
to go, my initial reaction is that things would be more clear if it all
can be covered in the architecture document. The fewer documents to have
to manage, the better.

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

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, January 29, 2007 4:19 AM
To: Lars Eggert
Cc: [email-masked]
Subject: RE: [PCN] 2nd charter text update

Dan

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 30 Jan 2007 11:51:17 -0500

Lars and all:
Please see my comments embedded below indicated/delimited by
KHC_START>
KHC_END>

Thanks!
-- Kwok --

>    Lars Eggert <[email-masked]>

KHC_START>
Lars: E-Mail address update needed?
KHC_END>

>    Lars Eggert <[email-masked]>

KHC_START>
Lars: E-Mail address update needed?
KHC_END>

>existing.

KHC_START>
IMHO, The following text needs to be improved.
To allow the text to be more concise and standardize what are needed
for inter-operability without shutting out innovations and possible
better ways of implementation.
KHC_END>

>These mechanisms operate at the domain edge, based on

KHC_START>
Suggested new text:
These mechanisms operate on the IP packet data path, with network nodes:
1. At the middle of the IP packet data path domain (interior nodes) performing
     measurement, detection, and indication of congestion and pre-congestion
     conditions.
2. At the edge of the IP packet data path domain (edge nodes) performing
    control of the IP packets that affect the congestion and pre-congestion
    conditions at the middle of the IP packet data path domain

The focus of the WG is on developing standards for specifying the detection
and indication behaviors at the interior nodes that is required for 
inter-operability.
The WG will use flow admission and flow preemption at the edge nodes as the
mechanism for controlling the IP packets that affect the congestion and
pre-congestion conditions at the middle of the IP packet data path domain.
The description of the behavior at the edge nodes may be a standards track
document if it is needed for inter-operability.
The WG may produce additional informational documents that describe some
possible methods for providing the required behaviors at the interior nodes and
edge nodes that supports the inter-operability of the standards developed here.
The WG may produce additional informational documents on how specific
quality-of-service polices can be implemented using a combination of these
mechanisms.
KHC_END>

>        on aggregated (pre-)congestion signals

KHC_START>
Suggest to replace:
"on aggregated (pre-)congestion signals"
by
"on aggregated (pre-)congestion information"
KHC_END>

>    (2) conditions under which interior routers generate

KHC_START>
Suggest to replace:
"(pre-)congestion signals"
by
"(pre-)congestion information"
KHC_END>

>    (3) encoding and transport of (pre-)congestion signals

KHC_START>
Suggest to replace:
"encoding and transport of (pre-)congestion signals"
by
"encoding and transport of aggregated (pre-)congestion information"
KHC_END>

>        to the appropriate ingress routers of the network domain

KHC_START>
Suggest to delete:
"to the appropriate ingress routers of the network domain"
The reasoning is we want to standardize how the (pre-)congestion
information is conveyed by the interior nodes to the edge nodes.
The deleted part of the sentence will confuse this point.  Hence I
suggest to delete it.
KHC_END>

>        rate adaption, based on aggregated (pre-)congestion information

KHC_START>
Suggest to replace:
"edge router control mechanisms ..."
by:
"behaviors of edge node control mechanisms ..."
or:
"edge node control behaviors ..."
KHC_END>

>and signaling interface needed to realize it.

KHC_START>
Suggest to replace:
"The WG focuses on the overall architecture and the marking behavior
and signaling interface needed to realize it."
by
"The WG focuses on the overall architecture and the marking behavior
and possible required external interfaces (e.g. to management, to 
signaling) needed to realize it."
KHC_END>

>Standards-track

KHC_START>
Suggest to replace:
"Standards-track protocols and mechanisms ..."
by
"Standards-track behaviors and mechanisms ..."
KHC_END>

>        where all edge and interior routers are PCN-enabled

KHC_START>
Suggest to replace:
"where all edge and interior routers ..."
by:
"where all edge and interior nodes ..."
KHC_END>

>concatenated DiffServ regions, PCN-aware application mechanisms,

KHC_START>
Suggest to replace:
"concatenated DiffServ regions, PCN-aware application mechanisms,"
by:
"concatenated DiffServ regions, end-to-end deployment of PCN mechanisms,"
KHC_END>

>mechanisms that act on (pre-)congestion signals. One example could be

KHC_START>
Suggest to replace:
"mechanisms that act on (pre-)congestion signals."
by:
"mechanisms that act on (pre-)congestion information."
KHC_END>

>            (Pre-)Congestion Signals within a DiffServ Region

KHC_START>
Suggest to replace:
"(Pre-)Congestion Signals ..."
by:
"(Pre-)Congestion Information ..."
KHC_END>

>            within a DiffServ Region to Flow Egress (Proposed Standard)

KHC_START>
Suggest to replace:
"Encoding and Transport of (Pre-)Congestion Signals
   within a DiffServ Region to Flow Egress (Proposed Standard)"
by
"Encoding and Transport of (Pre-)Congestion Information
   within a DiffServ Region (Proposed Standard)"
KHC_END>

>            DiffServ edge devices. (Proposed Standard)

KHC_START>
Suggest to delete:
"Mar 2008   Transport from Flow Egress in a DiffServ Region of
information
            (possibly aggregated) or Admission/Preemption Signals to
            DiffServ edge devices. (Proposed Standard)"
KHC_END>

---

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

> Lars: E-Mail address update needed?

Yes. Oops.

> pre-congestion conditions at the middle of the IP packet data path  

Talking about "nodes" and "paths" leaves the door open for other work  
than the routers-within-a-single-DiffServ-domain model that we want  
to focus the work on initially.

> document if it is needed for inter-operability.

Do you see a specific need for this to become standards track?

> quality-of-service polices can be implemented using a combination  

I'd rather not give the WG too many options to do additional  
Informational documents in the beginning. The focus should be on the  
standards track specifications.

> "on aggregated (pre-)congestion information"

OK (also elsewhere)

> The deleted part of the sentence will confuse this point.  Hence I

How will it confuse this point? It clarifies that we're not looking  
at transporting this information elsewhere, such as outside of the  
domain.

Lars

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 31 Jan 2007 18:50:25 -0500

LarsE, all:
Please see my response embedded below enclosed by KHC_START> and KHC_END>.
Thanks!
-- Kwok --

At 04:23 AM 1/31/2007, Lars Eggert wrote:
>>     measurement, detection, and indication of congestion and pre- congestion
>>     conditions.
>>    control of the IP packets that affect the congestion and pre- congestion

KHC_START>
The use of "IP packet data path" is just to make the proposed charter
more concise.  May be it becomes too wordy in the itemized sentences,
hence it will be OK for me if they are removed from the itemized sentences.
But I think "These mechanisms operate on the IP packet data path" at the top
is helpful to make the propose charter more clear and concise.

On the topic of using the words "nodes" and/or "routers".
I don't have a good understanding of why the word "router" must be there.
Many of today's "routers" perform "switching" instead of "routing".
And many of today's "routers" does more than just "routing".
Is a "blade-center" a "router"?  Part of it is a "router"?
And does the output (behavior, mechanism documentations) of this WG need to be
implemented on a specific hardware implementation?  On a specific physical box?
IMHO, the proposed-standards documents produced by this WG should indicate
behaviors and functionality.  To promote and assure inter-operability.
IMHO, the proposed-standards documents produced by this WG should NOT dictate
how the implementation is done, or where (which and what kind of 
square/round physical box)
the implementation must be done at.

I totally agree that we should focus on 
"within-a-single-DiffServ-domain" in the first phase.
IMHO, the usage of the word "nodes" does NOT "leaves the door open 
for other work" that
will be for NOT "within-a-single-DiffServ-domain".
Also, the usage of the word "routers" will NOT guarantee that we will 
just focus on
"within-a-single-DiffServ-domain".  (There are routers outside of 
DiffServ domains.)
IMHO, the propose charter is sufficiently clear that we are focusing on
"within-a-single-DiffServ-domain" for the initial phase.

Please accept my apology for being wordy here.
KHC_END>

>Do you see a specific need for this to become standards track?

KHC_START>
I think the required behavior (but NOT how it is implemented and NOT 
the exact algorithm
used) may need to be standards track for inter-operability reasons.
For example, the edge nodes may need to have the required behaviors 
of not allowing
more traffic be added to the (pre-)congested path(s) when 
(pre-)congestion condition
is indicated.
KHC_END>

>standards track specifications.

KHC_START>
How about we indicate ONE additional informational document that multiple
people in the BOF have indicated they will work on, that uses the standards
track specifications developed by this WG in the first phase?
KHC_END>

>at transporting this information elsewhere, such as outside of the

KHC_START>
Lars:
I believe you are talking about my comments to the itemized (3) in
the 2nd charter text update.
I found the statement:
"(3) encoding and transport of (pre-)congestion signals (replaced 
with information)
to the appropriate ingress routers of the network domain"
confusing because I believe we want to specify in a standards track document
how the (pre-)congestion information is encoded (the bits and bytes detail) in
some IP header field (ECN, DSCP, etc).
Based on my above interpretation, I see the mentioning of "ingress router"
confuses the purpose of (3).
I agree with the notion of "within-the-domain".  But it is pretty clear that is
the scope of our first phase.
Maybe (3) can be:
"(3) Encoding and transporting of (pre-)congestion information within 
the DiffServ domain".
KHC_END>