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

"Geib, Ruediger" <Ruediger.Geib@t-systems.com> Mon, 17 March 2008 15:33 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 4C7933A6D0F; Mon, 17 Mar 2008 08:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.749
X-Spam-Level:
X-Spam-Status: No, score=-100.749 tagged_above=-999 required=5 tests=[AWL=-0.312, 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 4JtTh4b30TCI; Mon, 17 Mar 2008 08:33:14 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A07C63A6BE0; Mon, 17 Mar 2008 08:33:14 -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 ACB6F3A6AA4 for <pcn@core3.amsl.com>; Mon, 17 Mar 2008 08:33:13 -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 YkPRpz9jHCmi for <pcn@core3.amsl.com>; Mon, 17 Mar 2008 08:33:07 -0700 (PDT)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id D96FF3A68B6 for <pcn@ietf.org>; Mon, 17 Mar 2008 08:33:06 -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 16:30:49 +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 16:30:49 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 17 Mar 2008 16:32:12 +0100
Message-Id: <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de>
In-Reply-To: <000601c8883b$e3828950$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/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymA=
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>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: karagian@cs.utwente.nl
X-OriginalArrivalTime: 17 Mar 2008 15:30:49.0356 (UTC) FILETIME=[E0AB2CC0:01C88843]
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,

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