[PCN] Comments /questions on LC-PCN draft

<philip.eardley@bt.com> Fri, 02 November 2007 15:57 UTC

Return-path: <pcn-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inyu4-0002mq-5j; Fri, 02 Nov 2007 11:57:48 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Inyu2-0002m2-PD for pcn-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 11:57:46 -0400
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inyu2-0002ib-CC for pcn@ietf.org; Fri, 02 Nov 2007 11:57:46 -0400
Received: from smtp1.smtp.bt.com ([]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Inytw-0003X0-K0 for pcn@ietf.org; Fri, 02 Nov 2007 11:57:41 -0400
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Nov 2007 15:57:39 +0000
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 02 Nov 2007 15:57:39 -0000
Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B342C7@E03MVZ1-UKDY.domain1.systemhost.net>
Thread-Topic: Comments /questions on LC-PCN draft
Thread-Index: AcgdaRfcltW5tnJLSLyJtQdPEU+OVw==
From: philip.eardley@bt.com
To: pcn@ietf.org
X-OriginalArrivalTime: 02 Nov 2007 15:57:39.0287 (UTC) FILETIME=[18152670:01C81D69]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035
Subject: [PCN] Comments /questions on LC-PCN draft
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1695423055=="
Errors-To: pcn-bounces@ietf.org

I've re-started the email thread.


Thanks Georgios for your description of LC-PCN in recent email. I'm
going to try & re-phrase how it works, partly to make sure I've
understood & partly to try and re-use the PCN terminology (I admit to
finding the translations required hard work). Hence it slightly repeats
some of my earlier email, but some of its different where I now
understand your scheme better


First, let me summarise to make sure I understand it right [fingers
crossed I do!].


- two encodings are used. one ('PCN-marking') is used for both adm ctrl
& termination to indicate the excess traffic. If a PCN-interior-node is
PCN-marking some pkts, then it marks all other pkts with another
encoding ('affected marking')


- the 'PCN-marking' algorithm has several regimes:

[let us assume that none of the packets arriving at an interface are

* when traffic rate is below PCN-lower-rate, no pkts are marked 

* as the traffic rate climbs above the PCN-lower-rate, an increasing
number of pkts are marked (marking rate = excess rate divided by N).
note, this applies whatever the traffic rate (the same formula, excess
rate divided by N, is used when the traffic rate is above the


* Fiddle factor 1: [applies to marking when rate is below
PCN-lower-rate] if pkts arrive already PCN-marked, then the node
measures the rate of pkts already marked & works out what excess rate
this corresponds to, and only marks additional pkts if its own excess
rate is even higher.

* Fiddle factor 2: [applies to marking when rate is above
PCN-upper-rate] assume that any rate above PCN-upper-rate, as measured
in the previous measurement window period T, will be in the process of
being terminated. So can ignore this much excess (above PCN-upper-rate)
in this measurement period.


* the PCN-egress-node measures the rate of PCN-marked pkts and
determines whether the overloaded node is in adm ctrl state or
termination ctrl state

* PCN-egress-node calculates the % of PCN-bytes that are PCN-marked,
multiplying by the N factor (to compensate for the PCN-interior-nodes
only marking 1/N of their excess rate). If above a certain % then new
calls are blocked. 

* PCN-egress-node also calculates the amount (bit rate) of PCN-bytes
that are PCN-marked (again multiplying by the N factor). If this is
above the PCN-upper-rate then it terminates some flows


* for a variety of reasons the following 4 factors have to be the same
on every node in the PCN-domain: N, T (sliding window measurement
period), [PCN-upper-rate - PCN-lower-rate], [(policed rate for the PCN
class) - PCN-upper-rate].




* imagine there are 2 independent ECMP paths for a particular
ingress-egress-aggregate, and that there's a PCN-interior-node on each
path that is somewhat pre-congested (traffic between PCN-lower-rate and
PCN-upper-rate - in 'adm ctrl state'). These add together at the
PCN-egress-node so it appears that some PCN-interior-node is highly
pre-congested (traffic above PCN-upper-rate). From your replies I
believe you agree. To try to get round this you've introduced a fiddle
factor, basically the PCN-egress-node has to see even more PCN-marks
before it really believes that flows need terminate. * the same
'affected marking' is used in both adm ctrl state & termination ctrl
state. Imagine that a node [node-1] on one ECMP path is in adm ctrl
state & a node [node-2] on another ECMP path is in termination ctrl
state. Therefore flows are terminated, and only flows that are being
PCN-marked or affected-marked are terminated. However this could lead to
flows being terminated that go through node-1; node-2 will still be just
as badly overloaded 

* one reading of these two bullets is that you haven't really solved

* there are a lot of parameters that need to be configured with the same
value everywhere in the PCN-domain. It would need careful thought about
what goes wrong if some of them are mis-configured on some PCN-nodes

* it's particularly foul if T (the measurement period) needs to be the
same on every PCN-node. I'm not sure this is really the case, but it
seemed to me to come out of "Fiddle factor 2"

* looking at the 2 rate parameters, [PCN-upper-rate - PCN-lower-rate],
[(policed rate for the PCN class) - PCN-upper-rate]. It seems quite
restrictive that these have to be the same on all PCN-nodes in the
PCN-domain. They might have very different capacities for instance. 

* the "fiddle factors" make the algorithm quite complicated I think for

* "fiddle factor 2" seems the wrong approach to me - I think it would be
better to keep marking at the same rate and for the PCN-egress-node to
terminate more slowly (in order to avoid the problem of terminating too
much). At least 2 reasons: if marked pkts are lost, then at best calls
take longer to be terminated (another measurement period before get
PCN-marks again) & at worst it might be possible to devise scenarios
where termination never happens; secondly, I think it makes it easier
for the PCN-egress-node to take account of policy [operator experience
etc] to decide how fast to react to overload, whereas your approach
fixes the speed of reaction as a parameter of the PCN-interior-node.


That's it for now!


best wishes





PCN mailing list