Re: [PCN] Concensus questions from Thursday's PCN meeting
"Geib, Ruediger" <Ruediger.Geib@t-systems.com> Mon, 17 March 2008 16:10 UTC
Return-Path: <pcn-bounces@ietf.org>
X-Original-To: ietfarch-pcn-archive@core3.amsl.com
Delivered-To: ietfarch-pcn-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B97528C40B; Mon, 17 Mar 2008 09:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.671
X-Spam-Level:
X-Spam-Status: No, score=-100.671 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8yq3VDQ805O; Mon, 17 Mar 2008 09:10:40 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A443A6C1A; Mon, 17 Mar 2008 09:10:39 -0700 (PDT)
X-Original-To: pcn@core3.amsl.com
Delivered-To: pcn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40323A6B88 for <pcn@core3.amsl.com>; Mon, 17 Mar 2008 09:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXB91fKddPuy for <pcn@core3.amsl.com>; Mon, 17 Mar 2008 09:10:36 -0700 (PDT)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 0F3883A6946 for <pcn@ietf.org>; Mon, 17 Mar 2008 09:10:35 -0700 (PDT)
Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Mon, 17 Mar 2008 17:08:18 +0100
Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Mar 2008 17:08:16 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 17 Mar 2008 17:09:39 +0100
Message-Id: <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de>
In-Reply-To: <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting
Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymAAAM8HgAAA8S7A
References: <BABC859E6D0B9A4D8448CC7F41CD2B0706181835@xmb-rtp-203.amer.cisco.com> <RrmbUrJK.1205679770.1867150.karagian@ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: karagian@cs.utwente.nl
X-OriginalArrivalTime: 17 Mar 2008 16:08:16.0711 (UTC) FILETIME=[1C325570:01C88849]
Cc: pcn@ietf.org
Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org
Hi Georgios, what I say is if PCN decides to deal with catastrophic events in combination with misconfigured routers, then it will end up standardising solutions for academic problems. Regards, Rudiger | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | Sent: Monday, March 17, 2008 4:38 PM | To: Geib, Rüdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | | Hi Ruediger | | I do not understand what you try to say. Please note that | flow termination is used for the below explained reason, see | below text taken from the PCN architecture draft: | | o The termination mechanism complements admission control. It | allows the network to recover from sudden unexpected surges of | PCN-traffic on some links, thus restoring QoS to the remaining | flows. Such scenarios are expected to be rare but not | impossible. | They can be caused by large network failures that | redirect lots of | admitted PCN-traffic to other links, or by malfunction of the | measurement-based admission control in the presence of admitted | flows that send for a while with an atypically low rate and then | increase their rates in a correlated way. | | Best regards, | Georgios | | | | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: maandag 17 maart 2008 16:32 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | > Hi Georgios, | > | > QoS on redundant links means, that one link is able to | carry the QoS | > traffic of the other. This may not hold for non QoS | traffic. This is, | > what typical carrier backbones providing QoS are engineered for | > (commonly known as traffic engineering). | > | > Should a misconfiguration occur, things may go wrong. | > Operational staff corrects this a soon as the misconfiguration is | > identified. | > | > The engineering of carrier backbones is often done with automated | > tools, leaving little room for human errors. | > However maintenance work may result in humanne system | interference. I | > doubt that Telekom's engineering department is willing to | accept extra | > protocol and router complexitiy to deal with operator configuration | > errors. While I time and again hear of the worst | misconfigs, I can't | > recall that my colleagues try to adapt standardisation afterwards. | > | > Regards, | > | > Rudiger | > | > | -----Original Message----- | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | Sent: Monday, March 17, 2008 3:34 PM | > | To: Geib, Rüdiger | > | Cc: pcn@ietf.org | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | | > | Hi Ruediger | > | | > | Please note that typical IP networks (thus not MPLS/GMPLS based | > | domains) can recover from failures by using rerouting. | > | Or do you know another standardized mechanism in typical IP | > networks | > | (thus not MPLS/GMPLS based) that can provide another kind | > of recovery | > | from failures. | > | | > | Furthermore, I will just explain the example again with maximum | > | capacity of | > | pathh2 being equal | > | to maximum capacity of path1 = C. | > | Please explain what you do not understand in this example! | > | | > | Here are the assumptions: | > | * In the PCN domain we assume that ECMP routing is possible! | > | * ingress-eggress-aggregate can contain flows that are | > passing through | > | one path or more paths (when ECMP routing is used). | > | | > | * routers are currently dropping packets randomly. Thus | marked and | > | unmarked packets will be | > | dropped randomly | > | | > | * When excess rate measurements are used, the triggering of | > admission | > | control and flow | > | termination are done at the egress by using the CLE. One | > example of | > | this trigger is: | > | CLE > 1%. Note that CLE = marked/(unmarked + marked). | This means | > | that if this trigger is not activated while a severe | > | congestion occurs in the PCN domain, then the operation | > of the PCN | > | domain will completely collapse. | > | | > | | > | My statement is: | > | If the routers do not preferentially drop marked packets | > then the PCN | > | domain operation, even in corner case and misconfiguration | > situations, | > | is more robust and more stable than in the situation that | > the router | > | is preferentially dropping marked packets. | > | | > | The below example show such a corner case! | > | | > | | > | I will describe two situations: | > | | > | Situation 1: | > | Consider that an ingress-egress-aggregate due to ECMP routing it | > | includes flows that are passing from at least two paths. | > | Assume that path1 supports a maximum bandwidth capacity of C. | > | Now consider that the maximum bandwdith capacity of path2 is C. | > | Consider also that both paths are fully utilized. | > | | > | Consider that preferentially marked packets are dropped and | > that path2 | > | fails. | > | Now assume that all (maximum) traffic passing through | path2 will be | > | rerouted through path1. | > | If a bottleneck router located in path1, say Rbott, is | > misconfigured | > | (i.e., from the point of view of having wrongly too high | > | configured-admissible-rate value), or even if it is well | > configured, | > | then it can be possible that CLE measured at the egress | > cannot reach | > | 1%. | > | Note that | > | CLE = marked packets/ (marked packets + unmarked packets). | > | This is because Rbott will just allow an excess rate to | > pass through | > | that is | > | | > | equal to: C - configured-admissible-rate. The rest of the marked | > | packets, so the rest of the excess rate, will be dropped | by Rbott, | > | since this router is preferentially dropping marked packets. | > | Furthermore, note that due to the ECMP routing flows that are | > | belonging to the same ingress-egress-aggregate and that | are passing | > | through another path, | > | | > | than path1, which is not congested, will forward traffic | > towards the | > | egress node that will be unmarked. | > | This will mean that the CLE > 1% will not be triggered, | > this will mean | > | that the flow termination will not be triggered and that | > the operation | > | of the PCN domain will collapse completely. | > | | > | | > | Situation 2: | > | Now consider that the router just operates as currently, i.e., no | > | preferential drop, randomly dropping marked and unmarked packets. | > | Consider also that the two paths described in Situation 1 | above are | > | used, ECMP routing is used, and that they are fully utilized. | > | Assume also that path2 fails and that the path2 traffic is | > rerouted on | > | path1. | > | Now the CLE value will have a higher probability of reaching the | > | triggering value of 1%. | > | | > | This is because the routers in path1 will drop randomly | marked and | > | unmarked packets. | > | It is more certain that in this case the CLE will reach 1% | > due to the | > | following reason. | > | In this example it is assumed that the maximum bandwidth capacity | > | supported by path2 is C. | > | This means that after rerouting the traffic from path2 into | > path1, the | > | ratio between marked packets and unmarked packets that | are passing | > | thorugh path1 can be equal or higher than 100%. | > | Note that the routers in path1 will mark the excess rate | > above C, thus | > | 1*C (i.e., the rerouted traffic from path2) as marked. | > | The above observation holds also for the situation that | the routers | > | are preferentially dropping unmarked packets. | > | | > | Thus when routers are preferentially dropping marked packets the | > | robustness of the PCN domain operation is decreasing and in | > some cases | > | it severely decreases, which could cause the complete | > collapse of the | > | PCN domain operation. | > | | > | Best regards, | > | Georgios | > | | > | | > | | > | | > | > -----Original Message----- | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > Sent: maandag 17 maart 2008 15:26 | > | > To: karagian@cs.utwente.nl | > | > Cc: pcn@ietf.org | > | > Subject: RE: [PCN] Concensus questions from Thursday's | PCN meeting | > | > | > | > Hi Georgios, | > | > | > | > Unfortunately you missed my point. | > | > | > | > No such thing as you describe has been, is or will for the | > | foreseeable | > | > future be engineered in the IP backbone of the company | > I'm working | > | > for. | > | > | > | > My expectation on the backbone of any carrier offering | > | transport QoS | > | > is, that it is engineered to survive probable failures | > (like single | > | > link losses) without impact on the performance of QoS | > | traffic. This is | > | > where we should start from, if we discuss PCN. From there | > | on, PCN is | > | > able to add value. | > | > | > | > Links without traffic engineering followed by | > misconfigured routers | > | > aren't the arguments which will convince either product | > | management or | > | > backbone engineering of the company I work for to deploy PCN. | > | > | > | > As a general comment: I don't regard PCN as a plug and | > play toy for | > | > the operational equivalent of a 'script kiddie'. If others | > | share that | > | > view and our documents don't state that, we should add text. | > | > | > | > Regards, | > | > | > | > Rudiger | > | > | > | > | -----Original Message----- | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | Sent: Monday, March 17, 2008 2:49 PM | > | > | To: Geib, Rüdiger | > | > | Cc: pcn@ietf.org | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > PCN meeting | > | > | | > | > | Hi Ruediger | > | > | | > | > | You missed my point! | > | > | The explanation applies to all types of IP networks. | > | > | Please note that the problem occurs also when path2 and | > path1 use | > | > | exactly the same maximum capacity, say C! | > | > | | > | > | In this case, if pathh2 fails then path1 will see an excess | > | > rate equal | > | > | to at least C. | > | > | The rest of the explanation is identical to the one used | > | during my | > | > | previous example! | > | > | | > | > | | > | > | | > | > | Best regards, | > | > | Georgios | > | > | | > | > | | > | > | | > | > | | > | > | | > | > | > -----Original Message----- | > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > | > Sent: maandag 17 maart 2008 14:34 | > | > | > To: karagian@cs.utwente.nl | > | > | > Cc: pcn@ietf.org | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's | > | PCN meeting | > | > | > | > | > | > Hi Georgios, | > | > | > | > | > | > What you describe isn't backbone traffic engineering. | > What you | > | > | > describe may happen in corporate VPNs, where a DSL access | > | > | is used to | > | > | > back up a WAN Fast Ethernet access or the like. I don't | > | > | object to have | > | > | > standards on PCN for VPNs, but I'm not interested in this | > | > issue for | > | > | > now. | > | > | > | > | > | > If you know any carrier who's operating his network with a | > | > | > 16:1 load balancing for QoS traffic on any particular link | > | > | set, please | > | > | > publish the name, we are all interested in hearing it. | > | > | > | > | > | > Regards, | > | > | > | > | > | > Rudiger | > | > | > | > | > | > | > | > | > | > | > | > | -----Original Message----- | > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | > | Sent: Monday, March 17, 2008 11:03 AM | > | > | > | To: Geib, Rüdiger | > | > | > | Cc: pcn@ietf.org | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > | > PCN meeting | > | > | > | | > | > | > | Hi Ruediger | > | > | > | | > | > | > | I will try to explain this more clearly. | > | > | > | Here are the assumptions: | > | > | > | * In the PCN domain we assume that ECMP routing | is possible! | > | > | > | * ingress-eggress-aggregate can contain flows that are | > | > | > passing through | > | > | > | one path or more paths (when ECMP routing is used). | > | > | > | | > | > | > | * routers are currently dropping packets randomly. Thus | > | > | marked and | > | > | > | unmarked packets will be | > | > | > | dropped randomly | > | > | > | | > | > | > | * When excess rate measurements are used, the | triggering of | > | > | > admission | > | > | > | control and flow | > | > | > | termination are done at the egress by using the CLE. One | > | > | > example of | > | > | > | this trigger is: | > | > | > | CLE > 1%. Note that CLE = marked/(unmarked + marked). | > | > | This means | > | > | > | that if this trigger is not activated while a severe | > | > | > | congestion occurs in the PCN domain, then the operation | > | > | > of the PCN | > | > | > | domain will completely collapse. | > | > | > | | > | > | > | | > | > | > | My statement is: | > | > | > | If the routers do not preferentially drop marked packets | > | > | > then the PCN | > | > | > | domain operation, even in corner case and misconfiguration | > | > | > situations, | > | > | > | is more robust and more stable than in the situation that | > | > | > the router | > | > | > | is preferentially dropping marked packets. | > | > | > | | > | > | > | The below example show such a corner case! | > | > | > | | > | > | > | | > | > | > | I will describe two situations: | > | > | > | | > | > | > | Situation 1: | > | > | > | Consider that an ingress-egress-aggregate due to ECMP | > | > routing it | > | > | > | includes flows that are passing from at least two paths. | > | > | > | Assume that path1 supports a maximum bandwidth | > capacity of C. | > | > | > | Now consider | > | > | > | that the maximum bandwdith capacity of path2 is 15*C. | > | > | > | Consider also that both paths are fully utilized. | > | > | > | | > | > | > | Consider that preferentially marked packets are | dropped and | > | > | > that path2 | > | > | > | fails. | > | > | > | Now assume that all (maximum) traffic passing through | > | > | path2 will be | > | > | > | rerouted through path1. | > | > | > | If a bottleneck router located in path1, say Rbott, is | > | > | > misconfigured | > | > | > | (i.e., from the point of view of having wrongly too high | > | > | > | configured-admissible-rate value), or even if it is well | > | > | > configured, | > | > | > | then it can be possible that CLE measured at the egress | > | > | > cannot reach | > | > | > | 1%. | > | > | > | Note that | > | > | > | CLE = marked packets/ (marked packets + unmarked packets). | > | > | > | This is because Rbott will just allow an excess rate to | > | > | > pass through | > | > | > | that is | > | > | > | | > | > | > | equal to: C - configured-admissible-rate. The rest of | > | > the marked | > | > | > | packets, so the rest of the excess rate, will be dropped | > | > | by Rbott, | > | > | > | since this router is preferentially dropping | marked packets. | > | > | > | Furthermore, note that due to the ECMP routing | > flows that are | > | > | > | belonging to the same ingress-egress-aggregate and that | > | > | are passing | > | > | > | through another path, | > | > | > | | > | > | > | than path1, which is not congested, will forward traffic | > | > | > towards the | > | > | > | egress node that will be unmarked. | > | > | > | This will mean that the CLE > 1% will not be triggered, | > | > | > this will mean | > | > | > | that the flow termination will not be triggered and that | > | > | > the operation | > | > | > | of the PCN domain will collapse completely. | > | > | > | | > | > | > | | > | > | > | Situation 2: | > | > | > | Now consider that the router just operates as | > | > currently, i.e., no | > | > | > | preferential drop, randomly dropping marked and | > | > unmarked packets. | > | > | > | Consider also that the two paths described in Situation 1 | > | > | above are | > | > | > | used, ECMP routing is used, and that they are fully | > utilized. | > | > | > | Assume also that path2 fails and that the path2 traffic is | > | > | > rerouted on | > | > | > | path1. | > | > | > | Now the CLE value will have a higher probability of | > | > reaching the | > | > | > | triggering value of 1%. | > | > | > | | > | > | > | This is because the routers in path1 will drop randomly | > | > | marked and | > | > | > | unmarked packets. | > | > | > | It is more certain that in this case the CLE will reach 1% | > | > | > due to the | > | > | > | following reason. | > | > | > | In this example it is assumed that the maximum | > | > bandwidth capacity | > | > | > | supported by path2 is 15*C. | > | > | > | This means that after rerouting the traffic from | path2 into | > | > | > path1, the | > | > | > | ratio between marked packets and unmarked packets that | > | > | are passing | > | > | > | thorugh path1 can be equal or higher than 16. | > | > | > | Note that the routers in path1 will mark the excess rate | > | > | > above C, thus | > | > | > | 16 * C (i.e., the rerouted traffic from path2) as marked. | > | > | > | The above observation holds also for the situation that | > | > | the routers | > | > | > | are preferentially dropping unmarked packets. | > | > | > | | > | > | > | Thus when routers are preferentially dropping marked | > | > packets the | > | > | > | robustness of the PCN domain operation is | decreasing and in | > | > | > some cases | > | > | > | it severely decreases, which could cause the complete | > | > | > collapse of the | > | > | > | PCN domain operation. | > | > | > | | > | > | > | Best regards, | > | > | > | Georgios | > | > | > | | > | > | > | | > | > | > | | > | > | > | | > | > | > | | > | > | > | > -----Original Message----- | > | > | > | > From: Geib, Ruediger | [mailto:Ruediger.Geib@t-systems.com] | > | > | > | > Sent: maandag 17 maart 2008 9:42 | > | > | > | > To: karagian@cs.utwente.nl | > | > | > | > Cc: pcn@ietf.org | > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's | > | > | PCN meeting | > | > | > | > | > | > | > | > Hi Georgios, | > | > | > | > | > | > | > | > PCN is designed for deployment in traffic engineered | > | > networks. | > | > | > | > Please decribe, how to engineer a high performance | > | > | > carrier backbone | > | > | > | > and then review the assumptions your discussion | > is based on. | > | > | > | > | > | > | > | > Regards, | > | > | > | > | > | > | > | > Rudiger | > | > | > | > | > | > | > | > | -----Original Message----- | > | > | > | > | From: Georgios Karagiannis | > [mailto:karagian@cs.utwente.nl] | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM | > | > | > | > | To: Geib, Rüdiger | > | > | > | > | Cc: pcn@ietf.org | > | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > | > | > PCN meeting | > | > | > | > | | > | > | > | > | Hi Ruediger | > | > | > | > | | > | > | > | > | What do you mean? | > | > | > | > | Do you mean that you do not want to discuss | corner cases | > | > | > | > (ECMP related | > | > | > | > | cases) that could | > | > | > | > | collapse the PCN domain operation? | > | > | > | > | What I am saying is that if the routers do not | > | > | > | preferentially drop | > | > | > | > | marked packets then the PCN domain operation is | > | more robust | > | > | > | > and more | > | > | > | > | stable than in the situation that the router is | > | > | preferentially | > | > | > | > | dropping marked packets. | > | > | > | > | | > | > | > | > | Are you saying that this statement is not right? | > | > | > | > | | > | > | > | > | | > | > | > | > | Best regards, | > | > | > | > | Georgios | > | > | > | > | | > | > | > | > | > | > | > | | > | > | > | | > | > | > | | > | > | > | > | > | | > | > | | > | > | | > | > | > | | > | | > | | > | | | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn
- [PCN] Concensus questions from Thursday's PCN mee… Steven Blake
- Re: [PCN] Concensus questions from Thursday's PCN… toby.moncaster
- Re: [PCN] Concensus questions from Thursday's PCN… Anna Charny (acharny)
- Re: [PCN] Concensus questions from Thursday's PCN… Steven Blake
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Anna Charny (acharny)
- Re: [PCN] Concensus questions from Thursday's PCN… Anna Charny (acharny)
- [PCN] [Fwd: RE: Concensus questions from Thursday… Steven Blake
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Wei Gengyu
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Steven Blake
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Steven Blake
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… philip.eardley
- Re: [PCN] Concensus questions from Thursday's PCN… Michael Menth
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Steven Blake
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… philip.eardley
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… philip.eardley
- Re: [PCN] Concensus questions from Thursday's PCN… toby.moncaster
- Re: [PCN] Concensus questions from Thursday's PCN… Anna Charny (acharny)
- Re: [PCN] Concensus questions from Thursday's PCN… Anna Charny (acharny)
- Re: [PCN] Concensus questions from Thursday's PCN… Wei Gengyu
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… philip.eardley
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Geib, Ruediger
- Re: [PCN] Concensus questions from Thursday's PCN… Anna Charny (acharny)
- Re: [PCN] Concensus questions from Thursday's PCN… Anna Charny (acharny)
- [PCN] Fw: Concensus questions from Thursday's PCN… Wei Gengyu
- [PCN] On pcn and overloads (was: Concensus questi… Anna Charny (acharny)
- Re: [PCN] On pcn and overloads (was: Concensus qu… Geib, Ruediger
- Re: [PCN] On pcn and overloads (was: Concensus qu… Anna Charny (acharny)
- Re: [PCN] On pcn and overloads (was: Concensus qu… toby.moncaster
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- [PCN] Georgios's example philip.eardley
- Re: [PCN] Concensus questions from Thursday's PCN… Steven Blake
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Georgios Karagiannis
- Re: [PCN] Concensus questions from Thursday's PCN… Michael Menth
- Re: [PCN] Concensus questions from Thursday's PCN… Michael Menth
- Re: [PCN] Concensus questions from Thursday's PCN… philip.eardley