Re: [PCN] Concensus questions from Thursday's PCN meeting

"Geib, Ruediger" <Ruediger.Geib@t-systems.com> Mon, 17 March 2008 13:34 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 ADCDA3A6DAE; Mon, 17 Mar 2008 06:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.789
X-Spam-Level:
X-Spam-Status: No, score=-100.789 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 9fsg8Buh6NBN; Mon, 17 Mar 2008 06:34:52 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF0C3A6D8D; Mon, 17 Mar 2008 06:34:52 -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 D776E3A6D6A for <pcn@core3.amsl.com>; Mon, 17 Mar 2008 06:34:51 -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 VduHwuvCbdrl for <pcn@core3.amsl.com>; Mon, 17 Mar 2008 06:34:47 -0700 (PDT)
Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 24CA128C199 for <pcn@ietf.org>; Mon, 17 Mar 2008 06:34:46 -0700 (PDT)
Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Mon, 17 Mar 2008 14:32:25 +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 14:32:24 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 17 Mar 2008 14:33:45 +0100
Message-Id: <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de>
In-Reply-To: <001301c88816$114dab60$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/rjB17BgABJ68gAABXALAAAifOMAAH2Kyw
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>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: karagian@cs.utwente.nl
X-OriginalArrivalTime: 17 Mar 2008 13:32:24.0542 (UTC) FILETIME=[55DE97E0:01C88833]
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 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