Subject: [PCN] PCN elevator speech

From: Tom Taylor <[email-masked]>
Date: Fri, 24 Apr 2009 18:39:24 -0400

Here is the text that is proposed to begin all PCN-related documents. Phil 
actually did the work, with input from others.

The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain, in
a simple, scalable and robust fashion. Two mechanisms are used:
admission control, to decide whether to admit or block a new flow
request, and (in abnormal circumstances) flow termination to decide
whether to terminate some of the existing flows. Together they protect
the QoS of previously admitted flows. To achieve this, the overall rate
of the PCN-traffic is metered on every link in the PCN-domain, and
PCN-packets are appropriately marked when certain configured rates are
exceeded. These configured rates are below the rate of the link thus
providing notification before any congestion occurs (hence
"pre-congestion notification"). The level of marking allows the boundary
nodes to make decisions about whether to admit or terminate. For a full 
description of the PCN architecure see [RFC xxxx (the architecture document)].

---

From: Tom Taylor <[email-masked]>
Date: Fri, 24 Apr 2009 19:06:25 -0400

Having said this, I would beg the indulgence of the group to modify the 
second-last sentence slightly, so it reads:

"The level of marking allows decisions to be made about whether to admit or 
terminate."

Tom Taylor wrote:
> Here is the text that is proposed to begin all PCN-related documents. 
> Phil actually did the work, with input from others.
> 
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 24 Apr 2009 16:53:33 -0700

I have an additional edit.

Generally, one doesn't configure a link to run full-bore and then  
scale back to deal with the traffic it has. r\Rather, one configures a  
link to deal effectively with specific application classes. For  
example, one will generally have a class for real-time traffic or  
separate classes for voice and video, with a separate class for  
elastic applications. This results in the real time traffic being  
handled in a way that serves its needs (it is guaranteed at most a  
given latency on a link so that e2e delay variation doesn't exceed  
some threshold), allowing elastic traffic to do the things it is  
famous for doing without interrupting real-time services.

As such, the reference to "the rate of the link" should refer to the  
"the rate allocated to a traffic class". If the class in fact occupies  
the whole link, the two statements are equivalent. If that observation  
gives heartburn, I would suggest "the rate of a traffic class, or  
where appropriate, a link".

It would also be very nice if we could somehow provide an architecture  
in which we are not using one mechanism differently for two different  
purposes, but using one mechanism to serve one purpose interpreted  
differently by different use cases. We are willing to have pre- 
congestion notification for voice/video/etc, but are willing to build  
queues for data in some cases, and in other cases have had suggestions  
that folks could similarly manage RFC 3168-like ECN based on traffic  
rates in elastic classes. If we are building an architecture for ECN  
in general of which PCN and RFC 3168 are special cases, then that  
should be reflected in this proposed text.

On Apr 24, 2009, at 4:06 PM, Tom Taylor wrote:

> Having said this, I would beg the indulgence of the group to modify  
> the second-last sentence slightly, so it reads:
>
> "The level of marking allows decisions to be made about whether to  
> admit or terminate."
>
> Tom Taylor wrote:
>> Here is the text that is proposed to begin all PCN-related  
>> documents. Phil actually did the work, with input from others.
>> nodes to make decisions about whether to admit or terminate. For a  
>> full description of the PCN architecure see [RFC xxxx (the  
>> architecture document)].

---

From: <[email-masked]>
Date: Wed, 29 Apr 2009 16:24:01 +0100

Fred

I agree with the sentiment of your first point. But:-

>>These configured rates are below the rate of the link thus providing
notification before any congestion occurs (hence "pre-congestion
notification").] 
the point of this sentence was simply to say that PCN is providing
notification before congestion occurs. In the main body of the doc, it
simply says things like " PCN-admissible-rate: the rate of PCN-traffic
on a link up to which PCN admission control should accept new
PCN-flows." - so hopefully it's clear that as you say you can configure
this value to be whatever you choose, ie what you want for this class of
traffic and not the full capacity of the link. 

on your second point, sorry if the following misunderstands. Is your
idea to use PCN-marking on elastic traffic? I believe that the marking
draft http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-02
allows this. although i don't think anyone's done any experiments. I
certainly hope that PCN marking will be useful in use cases beyond
admission control [but these wider cases are outside the current pcn
charter, and so not covered in the Architecture docm beyond a small
mention in the Appendix about possible future work].

Best wishes
phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fred
{ Baker
{ Sent: 25 April 2009 00:54
{ To: Tom Taylor
{ Cc: pcn
{ Subject: Re: [PCN] PCN elevator speech
{ 
{ I have an additional edit.
{ 
{ Generally, one doesn't configure a link to run full-bore and then
{ scale back to deal with the traffic it has. r\Rather, one configures a
{ link to deal effectively with specific application classes. For
{ example, one will generally have a class for real-time traffic or
{ separate classes for voice and video, with a separate class for
{ elastic applications. This results in the real time traffic being
{ handled in a way that serves its needs (it is guaranteed at most a
{ given latency on a link so that e2e delay variation doesn't exceed
{ some threshold), allowing elastic traffic to do the things it is
{ famous for doing without interrupting real-time services.
{ 
{ As such, the reference to "the rate of the link" should refer to the
{ "the rate allocated to a traffic class". If the class in fact occupies
{ the whole link, the two statements are equivalent. If that observation
{ gives heartburn, I would suggest "the rate of a traffic class, or
{ where appropriate, a link".
{ 
{ It would also be very nice if we could somehow provide an architecture
{ in which we are not using one mechanism differently for two different
{ purposes, but using one mechanism to serve one purpose interpreted
{ differently by different use cases. We are willing to have pre-
{ congestion notification for voice/video/etc, but are willing to build
{ queues for data in some cases, and in other cases have had suggestions
{ that folks could similarly manage RFC 3168-like ECN based on traffic
{ rates in elastic classes. If we are building an architecture for ECN
{ in general of which PCN and RFC 3168 are special cases, then that
{ should be reflected in this proposed text.
{ 
{ On Apr 24, 2009, at 4:06 PM, Tom Taylor wrote:
{ 
{ > Having said this, I would beg the indulgence of the group to modify
{ > the second-last sentence slightly, so it reads:
{ >
{ > "The level of marking allows decisions to be made about whether to
{ > admit or terminate."
{ >
{ > Tom Taylor wrote:
{ >> Here is the text that is proposed to begin all PCN-related
{ >> documents. Phil actually did the work, with input from others.
{ >> The objective of Pre-Congestion Notification (PCN) is to protect
the
{ >> quality of service (QoS) of inelastic flows within a Diffserv
{ >> domain, in
{ >> a simple, scalable and robust fashion. Two mechanisms are used:
{ >> admission control, to decide whether to admit or block a new flow
{ >> request, and (in abnormal circumstances) flow termination to decide
{ >> whether to terminate some of the existing flows. Together they
{ >> protect
{ >> the QoS of previously admitted flows. To achieve this, the overall
{ >> rate
{ >> of the PCN-traffic is metered on every link in the PCN-domain, and
{ >> PCN-packets are appropriately marked when certain configured rates
{ >> are
{ >> exceeded. These configured rates are below the rate of the link
thus
{ >> providing notification before any congestion occurs (hence
{ >> "pre-congestion notification"). The level of marking allows the
{ >> boundary
{ >> nodes to make decisions about whether to admit or terminate. For a
{ >> full description of the PCN architecure see [RFC xxxx (the
{ >> architecture document)].
{ >> _______________________________________________
{ >> PCN mailing list
{ >> [email-masked]
{ >> https://www.ietf.org/mailman/listinfo/pcn
{ > _______________________________________________
{ > PCN mailing list
{ > [email-masked]
{ > https://www.ietf.org/mailman/listinfo/pcn
{ 
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn

---

From: Fred Baker <[email-masked]>
Date: Wed, 29 Apr 2009 08:58:40 -0700

On Apr 29, 2009, at 8:24 AM, <[email-masked]> <[email-masked] 
 > wrote:

> idea to use PCN-marking on elastic traffic?

My point is that PCN builds on ECN, applying them same model to a  
different class of traffic (real time traffic). What I would like to  
see is a model that one might call "congestion notification", of which  
PCN and ECN are both special cases.