Subject: [PCN] PCN architecture, use of phrases like "exceeds rate"

From: Tina TSOU <[email-masked]>
Date: Sun, 30 Sep 2007 17:56:46 +0800

Hi,
See comments in line demarked with [Tina: ...] (:

B. R.
Tina

RE: [PCN] PCN architecture, use of phrases like "exceeds rate"

To: "Geib, Ruediger" <Ruediger.Geib at t-systems.com>, <philip.eardley at bt.com> 
Subject: RE: [PCN] PCN architecture, use of phrases like "exceeds rate" 
From: "Jozef Babiarz" <babiarz at nortel.com> 
Date: Wed, 19 Sep 2007 21:54:36 -0400 
Cc: pcn at ietf.org 
In-reply-to: <[email-masked]> 
List-archive: <http://www1.ietf.org/pipermail/pcn> 
List-help: <mailto:[email-masked]?subject=help> 
List-id: PCN WG list <pcn.ietf.org> 
List-post: <mailto:[email-masked]> 
List-subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:[email-masked]?subject=subscribe> 
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:[email-masked]?subject=unsubscribe> 
References: <[email-masked]> <[email-masked]> 
Thread-index: AcfZ4sD4MX/wup2KTYmWXZzVtqCqDAgo1F2AACdxudA= 
Thread-topic: [PCN] PCN architecture, use of phrases like "exceeds rate" 
Phil and others, since Ruediger email brought this to my attention. I have the following comments.
 
I think we should change the word “algorithm” to “marking behaviour” and “rate” to “threshold”. At least I believe that we should avoid specifying a specific algorithm but just define the behaviour of the algorithm. This would allow vendors to choose an algorithm that they believe gives best results. So would propose the following.
[Tina: The change is necessary for this new one is more explicit in meaning.]

<<Two traffic thresholds, a PCN-lower-threshold and a PCN-upper-threshold, can be associated with each link of the PCN-domain. Each traffic threshold has a marking behaviour(specified in another document) that determines how and when PCN-packets are marked, and how the markings are encoded in packet headers. PCN-egress-nodes make measurements of the packet markings and send information as necessary to the nodes that make the decision about which PCN-flow(s) to accept/reject or terminate, based on this information. Another document will describe decision-making behaviour. Overall the aim is to enable PCN-nodes to give an "early warning" of potential congestion before there is any significant build-up of PCN-packets in the queue; the admission control mechanism limits the PCN-traffic on each link to *roughly* its PCN-lower- threshold and the flow termination mechanism limits the PCN-traffic on each link to *roughly* its PCN-upper-threshold.>>
Regards, Joe 
email:babiarz at nortel.com 
Telephone:613-763-6098 

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